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The "xml2rfc" Version 3 Vocabulary 


Abstract 


This document defines the "xml2rfc" version 3 vocabulary: an 
XML-based language used for writing RFCs and Internet-Drafts. It is 
heavily derived from the version 2 vocabulary that is also under 
discussion. This document obsoletes the v2 grammar described in 

RFC 7749. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Architecture Board (IAB) 
and represents information that the IAB has deemed valuable to 
provide for permanent record. It represents the consensus of the 
Internet Architecture Board (IAB). Documents approved for 
publication by the IAB are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7991. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
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carefully, as they describe your rights and restrictions with respect 
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Introduction 


This document describes version 3 ("v3") of the "xml2rfc" vocabulary: 
an XML-based language ("Extensible Markup Language" [XML]) used for 
writing RFCs [RFC7322] and Internet-Drafts [IDGUIDE]. 


This document obsoletes the version 2 vocabulary ("v2") [RFC7749], 
which contains the extended language definition. That document in 
turn obsoletes the original version ("v1") [RFC2629]. This document 


directly copies the material from [RFC7749] where possible. 


The v3 format will be used as part of the new RFC Series format 
described in [RFC6949]. The new format will be handled by one or 
more new tools for preparing the XML and converting it to other 
representations. Features of the expected tools are described in 
Appendix B. That section defines some terms used throughout this 
document, such as "prep tool" and "formatter". 


Note that the vocabulary contains certain constructs that might not 
be used when generating the final text; however, they can provide 
useful data for other uses (such as index generation, populating a 
keyword database, or syntax checks). 


In this document, the term "format" is used when describing types of 
documents, primarily XML and HTML. The term "representation" is used 
when talking about a specific instantiation of a format, such as an 
XML document or an HTML document that was created by an XML document. 


1. Expected Updates to the Specification 


Non-interoperable changes in later versions of this specification are 
likely based on experience gained in implementing the new publication 
toolsets. Revised documents will be published capturing those 
changes as the toolsets are completed. Other implementers must not 
expect those changes to remain backwards-compatible with the details 
described in this document. 
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.2. Design Criteria for the Changes in v3 


The design criteria of the changes from v2 to v3 are as follows: 


O The intention is that starting and editing a v3 document will be 
easier than for a v2 document. 


o There will be good v2-to-v3 conversion tools for when an author 
wants to change versions. 


o There are no current plans to make v3 XML the required submission 
format for drafts or RFCs. That might happen eventually, but it 
is likely to be years away. 


There is a desire to keep as much of the v2 grammar as makes sense 
within the above design criteria and not to make gratuitous changes 
to the v2 grammar. Another way to say this is "we would rather 
encourage backwards compatibility but not be constrained by it." 
Still, the goal of starting and editing a v3 document being easier 
than for a v2 document is more important than backwards compatibility 
with v2, given the latter two design criteria. 


v3 is upwards compatible with v2, meaning that a v2 document is meant 
to be a valid v3 document as well. However, some features of v2 are 
deprecated in v3 in favor of new elements. Deprecated features are 
listed in Section 1.3.3 and are described in [RFC7749]. 


.3. Differences from v2 to v3 


This is a (hopefully) complete list of all the technical changes 
between [RFC7749] and this document. 


3.1. New Elements in v3 


o Add <dl>, <ul>, and <ol> as new ways to make lists. This is a 
significant change from v2 in that the child under these elements 
is <li>, not <t>. <li> has a model of either containing one or 
more <t> elements, or containing the flowing text normally found 
in <t>. These lists are children of <section>s and other lists 
instead of <t>. 


o Add <strong>, <em>, <tt>, <sub>, and <sup> for character 
formatting. 


o Add <aside> for incidental text that will be indented when 
displayed. 


o Add <sourcecode> to differentiate from <artwork>. 
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Add <table>, <thead>, <tbody>, <tfoot>, <tr>, <td>, and <th> to 
give table functionality like that in HTML. 


Add <boilerplate> to hold the automatically generated boilerplate 
text. 


Add <blockquote> to indicate a quotation as in a paragraph-like 
format. 


Add <name> to sections, notes, figures, and texttables to allow 
character formatting (fixed-width font) in their titles and to 


allow references in the names. 


Add <postalLine>, free text that represents one line of the 
address. 


Add <displayreference> to allow display of more mnemonic anchor 
names for automatically included references. 


Add <refcontent> to allow better control of text in a reference. 


Add <referencegroup> to allow referencing multi-RFC documents such 
as STDs and BCPs. 


Add <relref> to allow referencing specific sections or anchors in 
references. 


Add <link> to point to a resource related to the RFC. 


Add <br> to allow line breaks (but not blank lines) in the 
generated output for table cells. 


Add <svg> to allow easy inclusion of SVG drawings in <artwork>. 


New Attributes for Existing Elements 


Add "sortRefs", "symRefs", "tocDepth", and "tocInclude" attributes 
to <rfc> to cover Processing Instructions (PIs) that were in v2 
that are still needed in the grammar. Add "prepTime" to indicate 
the time that the XML went through a preparation step. Add 
"version" to indicate the version of xml2rfc vocabulary used in 
the document. Add "scripts" to indicate which scripts are needed 
to render the document. Add "expiresDate" when an Internet-Draft 
expires. 
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Add "ascii" attributes to <email>, <organization>, <street>, 
<city>, <region>, <country>, and <code>. Also add 
"asciiFullname", "asciilnitials", and "asciiSurname" to <author>. 
This allows an author to specify their information in their native 
scripts as the primary entry and still allow the ASCII-equivalent 
values to appear in the processed documents. 


Add "anchor" attributes to many block elements to allow them to be 
linked with <relref> and <xref>. 


Add the "section", "relative", and "sectionFormat" attributes to 
<xref>. 


Add the "numbered" and "removeInRFC" attributes to <section>. 
Add the "removeInRFC" attribute to <note>. 


Add "pn" to <artwork>, <aside>, <blockquote>, <boilerplate>, <dt>, 
<figure>, <iref>, <li>, <references>, <section>, <sourcecode>, 
<t>, and <table> to hold automatically generated numbers for items 
in a section that don’t have their own numbering (namely figures 
and tables). 


Add "display" to <cref> to indicate to tools whether or not to 
display the comment. 


Add "keepWithNext" and "keepWithPrevious" to <t> as a hint to 
tools that do pagination that they should try to keep the 


paragraph with the next/previous element. 


Elements and Attributes Deprecated from v2 


Deprecated elements and attributes are legacy vocabulary from v2 that 
are supported for input to v3 tools. They are likely to be removed 
from those tools in the future. Deprecated attributes are still 
listed in Section 2, and deprecated elements are listed in Section 3. 
See Appendix B for more information on tools and how they will handle 
deprecated features. 


o 


o 


o 


Deprecate <list> in favor of <dl>, <ul>, and <ol>. 
Deprecate <spanx>; replace it with <strong>, <em>, and <tt>. 


Deprecate <vspace> because the major use for it, creating pseudo- 
paragraph-breaks in lists, is now handled properly. 
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Deprecate <texttable>, <ttcol>, and <c>; replace them with the new 
table elements (<table> and the elements that can be contained 
within it). 


Deprecate <facsimile> because it is rarely used. 


Deprecate <format> because it is not useful and has caused 
surprise for authors in the past. If the goal is to provide a 
single URI (Uniform Resource Identifier) for a reference, use the 
"target" attribute in <reference> instead. 


Deprecate <preamble> and <postamble> in favor of simply using <t> 
before or after the figure. This also deprecates the "align" 


attribute in <figure>. 


Deprecate the "title" attribute in <section>, <note>, <figure>, 
<references>, and <texttable> in favor of the new <name>. 


Deprecate the "alt" and "src" attributes in <figure> because they 
overlap with the attributes in <artwork>. 


Deprecate the "xml:space" attribute in <artwork> because there was 
only one useful value. Deprecate the "height" and "width" 
attributes in both <artwork> and <figure> because they are not 
needed for the new output formats. 

Deprecate the "pageno" attribute in <xref> because it was unused 
in v2. Deprecate the "none" values for the "format" attribute in 
<xref> because it makes no sense semantically. 


Additional Changes from v2 


Allow non-ASCII characters in the format; the characters that are 
actually allowed will be determined by the RFC Series Editor. 


Allow <artwork> and <sourcecode> to be used on their own in 
<section> (no longer confine them to a figure). 


Give more specifics of handling the "type" attribute in <artwork>. 
Allow <strong>, <em>, <tt>, <eref>, and <xref> in <cref>. 
Allow the sub-elements inside a <reference> to be in any order. 


Turn off the autogeneration of anchors in <cref> because there is 
no use case for them that cannot be achieved in other ways. 
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o Allow more than one <artwork>, or more than one <sourcecode>, in 
<figure>. 
o In <front>, make <date> optional. 


o In <date>, add restrictions to the "date" and "year" attributes 
when used in the <front> for the document’s boilerplate text. 


o In <postal>, allow the sub-elements to be in any order. Also 
allow the inclusion of the new <postalLine> instead of the older 
elements. 


o In <section>, restrict the names of the anchors that can be used 
on some types of sections. 


o Make <seriesInfo> a child of <front>, and deprecated it as a child 
of <reference>. This also deprecates some of the attributes from 


<rfc> and moves them into <seriesInfo>. 


o <t> now only contains non-block elements, so it no longer contains 
<figure> elements. 


o Do not generate the grammar from a DTD, but instead get it 
directly from the RELAX Next Generation (RNG) grammar [RNG]. 


1.4. Syntax Notation 
The XML vocabulary here is defined in prose, based on the RELAX NG 
schema [RNC] contained in Appendix C (specified in RELAX NG Compact 
Notation (RNC)). 
Note that the schema can be used for automated validity checks, but 
certain constraints are only described in prose (example: the 
conditionally required presence of the "abbrev" attribute). 


2. Elements 


The sections below describe all elements and their attributes. 


Note that attributes not labeled "mandatory" are optional. 


Many elements have an optional "anchor" attribute. In all cases, the 
value of the "anchor" attribute needs to be a valid XML "Name" 
(Section 2.3 of [XML]), additionally constrained to US-ASCII 
characters [USASCII]. Thus, the character repertoire consists of 
"a-z", "a-z", "0-9", rows vim WE and Mam where "0-9", mM and 
"—" are disallowed as start characters. Anchors are described in 
more detail in Appendix B.2. 
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Tools interpreting the XML described here will collapse horizontal 
whitespace and line breaks to a single whitespace (except inside 
<artwork> and <sourcecode>) and will trim leading and trailing 
whitespace. Tab characters (U+0009) inside <artwork> and 
<sourcecode> are prohibited. 


Some of the elements have attributes that are not described in this 
section because those attributes are specific to the prep tool. 
People writing tools to process this format should read all of the 
appendices for a complete description of these attributes. 

Every element in the v3 vocabulary can have an "xml:lang" attribute, 
an "xml:base" attribute, or both. The xml:lang attribute specifies 
the language used in the element. This is sometimes useful for 
renderers that display different fonts for ideographic characters 
used in China and Japan. The xml:base attribute is sometimes added 
to an XML file when doing XML-to-XML conversion where the base file 
has XInclude attributes (see Appendix B.1). 

<abstract> 


Contains the Abstract of the document. See [RFC7322] for more 
information on restrictions for the Abstract. 


This element appears as a child element of <front> (Section 2.26). 
Content model: 

In any order, but at least one of: 

o <dl> elements (Section 2.20) 

o <ol> elements (Section 2.34) 

o <t> elements (Section 2.53) 

o <ul> elements (Section 2.63) 

.1. "anchor" Attribute 


Document-wide unique identifier for the Abstract. 


Hoffman Informational [Page 11] 


RFC 7991 


2.2. <address> 


The "xml2rfc" Version 3 Vocabulary 


Provides address information for the author. 


This element appears as a child element of <author> 


Content model: 


December 2016 


(Section 2.7). 


In this order: 
1. One optional <postal> element (Section 2.37) 
2. One optional <phone> element (Section 2.36) 
3. One optional <facsimile> element (Section 3.2) 
4. One optional <email> element (Section 2.23) 
5. One optional <uri> element (Section 2.64) 
2.3. <annotation> 
Provides additional prose augmenting a bibliographic reference. This 


text is intended to be shown after the rest of the generated 
reference text. 


This element appears as a child element of <reference> 


(Section 2.40). 


Content model: 


In any order: 


o Text 


o  <bcp14> elements (Section 2.9) 


o <cref> elements (Section 2.16) 


o <em> elements 


(Section 2.22) 


o <eref> elements (Section 2.24) 


o <iref> elements (Section 2.27) 


o <relref> elements (Section 2.44) 


o <spanx> elements (Section 3.7) 
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o <strong> elements (Section 2.50) 

o <sub> elements (Section 2.51) 

o <sup> elements (Section 2.52) 

o <tt> elements (Section 2.62) 

o <xref> elements (Section 2.66) 
2.4. <area> 


Provides information about the IETF area to which this document 
relates (currently not used when generating documents). 


The value ought to be either the full name or the abbreviation of one 
of the IETF areas as listed on <http://www.ietf.org/iesg/area.html>. 
A list of full names and abbreviations will be kept by the RFC Series 
Editor. 


This element appears as a child element of <front> (Section 2.26). 
Content model: only text content. 
2.5. <artwork> 


This element allows the inclusion of "artwork" in the document. 
<artwork> provides full control of horizontal whitespace and line 
breaks; thus, it is used for a variety of things, such as diagrams 
("line art") and protocol unit diagrams. Tab characters (U+0009) 
inside of this element are prohibited. 


Alternatively, the "src" attribute allows referencing an external 
graphics file, such as a vector drawing in SVG or a bitmap graphic 
file, using a URI. In this case, the textual content acts as a 
fallback for output representations that do not support graphics; 
thus, it ought to contain either (1) a "line art" variant of the 
graphics or (2) prose that describes the included image in sufficient 
detail. 


In [RFC7749], the <artwork> element was also used for source code and 
formal languages; in v3, this is now done with <sourcecode>. 
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There are at least five ways to include SVG in artwork in 
Internet-Drafts: 


o Inline, by including all of the SVG in the content of the element, 
such as: <artwork type="svg"><svg xmlns="http://www.w3.org/2000/ 
svg..."> 


o Inline, but using XInclude (see Appendix B.1), such as: <artwork 
type="sSvg"><xi:include href=...> 


o As a data: URI, such as: <artwork type="svg" src="data:image/ 
svgtxml, $3Csvg%S20xmlnsS3D%22https3AS2FS2Fwww.w3..."> 


o As a URI to an external entity, such as: <artwork type="svg" 
src="http://www.example.com/..."> 


o As a local file, such as: <artwork type="svg" src="diagraml2.svg"> 


The use of SVG in Internet-Drafts and RFCs is covered in much more 
detail in [RFC7996]. 


The above methods for inclusion of SVG art can also be used for 
including text artwork, but using a data: URI is probably confusing 
for text artwork. 


Formatters that do pagination should attempt to keep artwork on a 
single page. This is to prevent artwork that is split across pages 
from looking like two separate pieces of artwork. 


See Section 5 for a description of how to deal with issues of using 
"E" and "<" characters in artwork. 


This element appears as a child element of <aside> (Section 2.6), 
<blockquote> (Section 2.10), <dd> (Section 2.18), <figure> 

(Section 2.25), <li> (Section 2.29), <section> (Section 2.46), <td> 
(Section 2.56), and <th> (Section 2.58). 

Content model: 


Either: 


Text 


<svg> elements (Section 4) 
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2.5.1. "align" Attribute 
Controls whether the artwork appears left justified (default), 
centered, or right justified. Artwork is aligned relative to the 
left margin of the document. 


Allowed values: 


o "left" (default) 


o "center" 
o "right" 
2: DL "alt" Attribute 


Alternative text description of the artwork (which is more than just 
a summary or caption). When the art comes from the "src" attribute 
and the format of that artwork supports alternate text, the 
alternative text comes from the text of the artwork itself, not from 
this attribute. The contents of this attribute are important to 
readers who are visually impaired, as well as those reading on 
devices that cannot show the artwork well, or at all. 


BES "anchor" Attribute 


Document-wide unique identifier for this artwork. 


2.5.4. "height" Attribute 
Deprecated. 
2.5.5. "name" Attribute 


A filename suitable for the contents (such as for extraction to a 
local file). This attribute can be helpful for other kinds of tools 
(such as automated syntax checkers, which work by extracting the 
artwork). Note that the "name" attribute does not need to be unique 
for <artwork> elements in a document. If multiple <artwork> elements 
have the same "name" attribute, a processing tool might assume that 
the elements are all fragments of a single file, and the tool can 
collect those fragments for later processing. See Section 7 for a 
discussion of possible problems with the value of this attribute. 
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2s 


Sab "src" Attribute 


The URI reference of a graphics file [RFC3986], or the name of a file 
on the local disk. This can be a "data" URI [RFC2397] that contains 
the contents of the graphics file. Note that the inclusion of art 
with the "src" attribute depends on the capabilities of the 
processing tool reading the XML document. Tools need to be able to 
handle the file: URI, and they should be able to handle http: and 
https: URIs as well. The prep tool will be able to handle reading 
the "src" attribute. 


If no URI scheme is given in the attribute, the attribute is 
considered to be a local filename relative to the current directory. 
Processing tools must be careful to not accept dangerous values for 
the filename, particularly those that contain absolute references 
outside the current directory. Document creators should think hard 
before using relative URIs due to possible later problems if files 
move around on the disk. Also, documents should most likely use 
explicit URI schemes wherever possible. 


In some cases, the prep tool may remove the "src" attribute after 
processing its value. See [RFC7998] for a description of this. 


It is an error to have both a "src" attribute and content in the 
<artwork> element. 


.5.7. "type" Attribute 


Specifies the type of the artwork. The value of this attribute is 
free text with certain values designated as preferred. 


The preferred values for <artwork> types are: 
o ascii-art 

o binary-art 

o call-flow 

o hex-dump 


o svg 
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The RFC Series Editor will maintain a complete list of the preferred 
values on the RFC Editor web site, and that list is expected to be 
updated over time. Thus, a consumer of v3 XML should not cause a 
failure when it encounters an unexpected type or no type is 
specified. The table will also indicate which type of art can appear 
in plain-text output (for example, type="svg" cannot). 


8. "width" Attribute 
Deprecated. 
.9. "xml:space" Attribute 
Deprecated. 
<aside> 


This element is a container for content that is semantically less 
important or tangential to the content that surrounds it. 


This element appears as a child element of <section> (Section 2.46). 
Content model: 

In any order: 

o <artwork> elements (Section 2.5) 
o <dl> elements (Section 2.20) 

o <figure> elements (Section 2.25) 
o <iref> elements (Section 2.27) 

o <list> elements (Section 3.4) 

o <ol> elements (Section 2.34) 

o <t> elements (Section 2.53) 

o <table> elements (Section 2.54) 
o <ul> elements (Section 2.63) 

1. "anchor" Attribute 


Document-wide unique identifier for this aside. 
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2.7. <author> 


Provides information about a document’s author. This is used both 
for the document itself (at the beginning of the document) and for 
referenced documents. 


The <author> elements contained within the document’s <front> element 
are used to fill the boilerplate and also to generate the "Author’s 
Address" section (see [RFC7322]). 


Note that an "author" can also be just an organization (by not 
specifying any of the "name" attributes, but adding the 
<organization> child element). 


Furthermore, the "role" attribute can be used to mark an author as 
"editor". This is reflected both on the front page and in the 
"Author’s Address" section, as well as in bibliographic references. 
Note that this specification does not define a precise meaning for 
the term "editor". 

This element appears as a child element of <front> (Section 2.26). 


Content model: 


In this order: 


1. One optional <organization> element (Section 2.35) 
2. One optional <address> element (Section 2.2) 
2.7.1. "asciiFullname" Attribute 


The ASCII equivalent of the author’s full name. 
2.7.2. "asciilnitials" Attribute 


The ASCIT equivalent of the author's initials, to be used in 
conjunction with the separately specified asciiSurname. 


2 he Bs "asciiSurname" Attribute 


The ASCII equivalent of the author’s surname, to be used in 
conjunction with the separately specified asciilnitials. 
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Lido "fullname" Attribute 


The full name (used in the automatically generated "Author's Address" 
section). Although this attribute is optional, if one or more of the 
"asciiFullname", "asciilnitials", or "asciiSurname" attributes have 
values, the "fullname" attribute is required. 


2.7.5. "initials" Attribute 
An abbreviated variant of the given name(s), to be used in 


conjunction with the separately specified surname. It usually 
appears on the front page, in footers, and in references. 


Some processors will post-process the value -- for instance, when it 
only contains a single letter (in which case they might adda 
trailing dot). Relying on this kind of post-processing can lead to 


results varying across formatters and thus ought to be avoided. 
2.7.6. "role" Attribute 

Specifies the role the author had in creating the document. 

Allowed value: 

o "editor" 
2.7.7. "surname" Attribute 

The author’s surname, to be used in conjunction with the separately 

specified initials. It usually appears on the front page, in 


footers, and in references. 


2.8. <back> 


Contains the "back" part of the document: the references and 
appendices. In <back>, <section> elements indicate appendices. 


This element appears as a child element of <rfc> (Section 2.45). 
Content model: 


In this order: 


1. Optional <displayreference> elements (Section 2.19) 
2. Optional <references> elements (Section 2.42) 
3. Optional <section> elements (Section 2.46) 
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2.9. <bcp14> 
Marks text that are phrases defined in [BCP14] such as "MUST", 
"SHOULD NOT", and so on. When shown in some of the output 
representations, the text in this element might be highlighted. The 
use of this element is optional. 
This element is only to be used around the actual phrase from BCP 14, 
not the full definition of a requirement. For example, it is correct 
to say "The packet <bcp14>MUST</bcp14> be dropped.", but it is not 
correct to say "<bcp14>The packet MUST be dropped.</bcp14>". 
This element appears as a child element of <annotation> 
(Section 2.3), <blockquote> (Section 2.10), <dd> (Section 2.18), <dt> 
(Section 2.21), <em> (Section 2.22), <li> (Section 2.29), <preamble> 
(Section 3.6), <refcontent> (Section 2.39), <strong> (Section 2.50), 
<sub> (Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td> 
(Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62). 
Content model: only text content. 
2.10. <blockquote> 

Specifies that a block of text is a quotation. 
This element appears as a child element of <section> (Section 2.46). 
Content model: 
Either: 

In any order, but at least one of: 

* <artwork> elements (Section 2.5) 

* <dl> elements (Section 2.20) 

* <figure> elements (Section 2.25) 

* <ol> elements (Section 2.34) 

* <sourcecode> elements (Section 2.48) 


* <t> elements (Section 2.53) 


* <ul> elements (Section 2.63) 
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In any order, but at least one of: 
* Text 
* <bcp14> elements (Section 2.9) 
* <cref> elements (Section 2.16) 
* <em> elements (Section 2.22) 
* <eref> elements (Section 2.24) 
* <iref> elements (Section 2.27) 
* <relref> elements (Section 2.44) 
* <strong> elements (Section 2.50) 
* <sub> elements (Section 2.51) 
* <sup> elements (Section 2.52) 
* <tt> elements (Section 2.62) 
* <xref> elements (Section 2.66) 
2.10.1. "anchor" Attribute 
Document-wide unique identifier for this quotation. 
2.10.2. "cite" Attribute 
The source of the citation. This must be a URI. If the "quotedFrom" 
attribute is given, this URI will be used by processing tools as the 
link for the text of that attribute. 
2.10.3. "quotedFrom" Attribute 
Name of person or document the text in this element is quoted from. 


A formatter should render this as visible text at the end of the 
quotation. 
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2.11. <boilerplate> 


Holds the boilerplate text for the document. This element is filled 
in by the prep tool. 


This element contains <section> elements. Every <section> element in 
this element must have the "numbered" attribute set to "false". 


This element appears as a child element of <front> (Section 2.26). 
Content model: 
One or more <section> elements (Section 2.46) 

2.12. <br> 
Indicates that a line break should be inserted in the generated 
output by a formatting tool. Multiple successive instances of this 


element are ignored. 


This element appears as a child element of <td> (Section 2.56) and 
<th> (Section 2.58). 


Content model: this element does not have any contents. 
LL eo “SCLEY> 
Gives the city name in a postal address. 
This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 
2.13.1. "ascii" Attribute 
The ASCII equivalent of the city name. 
2.14. <code> 
Gives the postal region code. 
This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 
2.14.1. "ascii" Attribute 


The ASCII equivalent of the postal code. 
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2.15. <country> 
Gives the country name or code in a postal address. 
This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 

2.15.1. "ascii" Attribute 
The ASCII equivalent of the country name. 

2.16. <cref> 
Represents a comment. 
Comments can be used in a document while it is work in progress. 
They might appear either inline and visually highlighted, at the end 
of the document, or not at all, depending on the formatting tool. 
This element appears as a child element of <annotation> 
(Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <dd> 
(Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <name> (Section 2.32), <postamble> (Section 3.5), 
<preamble> (Section 3.6), <strong> (Section 2.50), <sub> 
(Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td> 
(Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol> 
(Section 3.9). 
Content model: 
In any order: 
o Text 
o <em> elements (Section 2.22) 
o <eref> elements (Section 2.24) 


o <relref> elements (Section 2.44) 


o <strong> elements (Section 2.50) 
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o <sub> elements (Section 2.51) 

o <sup> elements (Section 2.52) 

o <tt> elements (Section 2.62) 

o <xref> elements (Section 2.66) 
2.16.1. "anchor" Attribute 

Document-wide unique identifier for this comment. 
2.16.2. "display" Attribute 


Suggests whether or not the comment should be displayed by formatting 


tools. This might be set to "false" if you want to keep a comment in 
a document after the contents of the comment have already been dealt 
with. 


Allowed values: 
o "true" (default) 
o "false" 
2.16.3. "source" Attribute 


Holds the "source" of a comment, such as the name or the initials of 
the person who made the comment. 


2.17. <date> 


Provides information about the publication date. This element is 
used for two cases: the boilerplate of the document being produced, 
and inside bibliographic references that use the <front> element. 


Boilerplate for Internet-Drafts and RFCs: This element defines the 
date of publication for the current document (Internet-Draft or 
RFC). When producing Internet-Drafts, the prep tool uses this 
date to compute the expiration date (see [IDGUIDE]). When one or 
more of "year", "month", or "day" are left out, the prep tool will 
attempt to use the current system date if the attributes that are 
present are consistent with that date. 


In dates in <rfc> elements, the month must be a number or a month 


in English. The prep tool will silently change text month names 
to numbers. Similarly, the year must be a four-digit number. 
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When the prep tool is used to create Internet-Drafts, it will 
reject a submitted Internet-Draft that has a <date> element in the 
boilerplate for itself that is anything other than today. That 
is, the tool will not allow a submitter to specify a date other 
than the day of submission. To avoid this problem, authors might 
simply not include a <date> element in the boilerplate. 


Bibliographic references: In dates in <reference> elements, the date 
information can have prose text for the month or year. For 
example, vague dates (year="ca. 2000"), date ranges 
(year="2012-2013"), non-specific months (month="Second quarter"), 
and so on are allowed. 


This element appears as a child element of <front> (Section 2.26). 
Content model: this element does not have any contents. 
2.17.1. "day" Attribute 
The day of publication. 
2.17.2. "month" Attribute 
The month or months of publication. 
2.17.3. "year" Attribute 
The year or years of publication. 
2.18. <dd> 
The definition part of an entry in a definition list. 
This element appears as a child element of <dl> (Section 2.20). 
Content model: 
Either: 
In any order, but at least one of: 
*  <artwork> elements (Section 2.5) 
* <dl> elements (Section 2.20) 
* <figure> elements (Section 2.25) 


* <ol> elements (Section 2.34) 
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<sourcecode> elements (Section 2.48) 
<t> elements (Section 2.53) 


<ul> elements (Section 2.63) 


any order, but at least one of: 
Text 

<bcp14> elements (Section 2.9) 
<cref> elements (Section 2.16) 
<em> elements (Section 2.22) 
<eref> elements (Section 2.24) 
<iref> elements (Section 2.27) 
<relref> elements (Section 2.44) 
<strong> elements (Section 2.50) 
<sub> elements (Section 2.51) 
<sup> elements (Section 2.52) 
<tt> elements (Section 2.62) 
<xref> elements (Section 2.66) 


"anchor" Attribute 


Informational 


December 2016 
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2.19. <displayreference> 


This element gives a mapping between the anchor of a reference anda 
name that will be displayed instead. This allows authors to display 
more mnemonic anchor names for automatically included references. 
The mapping in this element only applies to <xref> elements whose 
format is "default". For example, if the reference uses the anchor 
"RFC6949", the following would cause that anchor in the body of 
displayed documents to be "RFC-dev": 


<displayreference target="RFC6949" to="RFC-dev"/> 


If a reference section is sorted, this element changes the sort 
order. 


It is expected that this element will only be valid in input 
documents. It will likely be removed by prep tools when preparing a 
final version after those tools have replaced all of the associated 
anchors, targets, and "derivedContent" attributes. 

This element appears as a child element of <back> (Section 2.8). 
Content model: this element does not have any contents. 


2.19.1. "target" Attribute (Mandatory) 


This attribute must be the name of an anchor in a <reference> or 
<referencegroup> element. 


2.19.2. "to" Attribute (Mandatory) 


This attribute is a name that will be displayed as the anchor instead 


of the anchor that is given in the <reference> element. The string 
given must start with one of the following characters: 0-9, a-z, or 
A-Z. The other characters in the string must be 0-9, a-z, A-Z, "-", 
" " or " " 

r = 


2.20. <dl> 


A definition list. Each entry has a pair of elements: a term (<dt>) 
and a definition (<dd>). (This is slightly different and simpler 
than the model used in HTML, which allows for multiple terms for a 
single definition.) 


This element appears as a child element of <abstract> (Section 2.1), 
<aside> (Section 2.6), <blockquote> (Section 2.10), <dd> 

(Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section> 
(Section 2.46), <td> (Section 2.56), and <th> (Section 2.58). 
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Content model: 
One or more sequences of: 
1. One <dt> element 
2. One <dd> element 
2.20.1. "anchor" Attribute 
Document-wide unique identifier for the list. 


2.20.2. "hanging" Attribute 


The "hanging" attribute defines whether or not the term appears on 
the same line as the definition. hanging="true" indicates that the 
term is to the left of the definition, while hanging="false" 
indicates that the term will be on a separate line. 
Allowed values: 
o "false" 
o "true" (default) 

2.20.3. "spacing" Attribute 
Defines whether or not there is a blank line between entries. 
spacing="normal" indicates a single blank line, while 
spacing="compact" indicates no space between. 
Allowed values: 


o "normal" (default) 


o "compact" 
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2.21. <dt> 


The term being defined in a definition list. 


This element appears as a child element of <dl> (Section 2.20). 

Content model: 

In any order: 

o Text 

o <bcp14> elements (Section 2.9) 

o <cref> elements (Section 2.16) 

o <em> elements (Section 2.22) 

o <eref> elements (Section 2.24) 

o <iref> elements (Section 2.27) 

o <relref> elements (Section 2.44) 

o <strong> elements (Section 2.50) 

o <sub> elements (Section 2.51) 

o <sup> elements (Section 2.52) 

o <tt> elements (Section 2.62) 

o <xref> elements (Section 2.66) 
2.21.1. "anchor" Attribute 


Document-wide unique identifier for this term. 
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2.22. <em> 
Indicates text that is semantically emphasized. Text enclosed within 
this element will be displayed as italic after processing. This 
element can be combined with other character formatting elements, and 
the formatting will be additive. 
This element appears as a child element of <annotation> 
(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <li> (Section 2.29), 
<preamble> (Section 3.6), <refcontent> (Section 2.39), <strong> 
(Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t> 
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and <tt> 
(Section 2.62). 
Content model: 
In any order: 
o Text 
o <bcpl4> elements (Section 2.9) 
o <cref> elements (Section 2.16) 
o <eref> elements (Section 2.24) 
o <iref> elements (Section 2.27) 
o <relref> elements (Section 2.44) 
o <strong> elements (Section 2.50) 
o <sub> elements (Section 2.51) 
o <sup> elements (Section 2.52) 


o <tt> elements (Section 2.62) 


o <xref> elements (Section 2.66) 


Hoffman Informational [Page 30] 


RFC 7991 The "xml2rfc" Version 3 Vocabulary December 2016 


2.23. <email> 
Provides an email address. 


The value is expected to be the addr-spec defined in Section 2 of 
[RFC6068]. 


This element appears as a child element of <address> (Section 2.2). 
Content model: only text content. 
2.23.1. "ascii" Attribute 


The ASCII equivalent of the author’s email address. This is only 
used if the email address has any internationalized components. 


2.24. <eref> 


Represents an "external" link (as specified in the "target" 
attribute). This is useful for embedding URIs in the body of a 
document . 


If the <eref> element has non-empty text content, formatters should 
use the content as the displayed text that is linked. Otherwise, the 
formatter should use the value of the "target" attribute as the 
displayed text. Formatters will link the displayed text to the value 
of the "target" attribute in a manner appropriate for the output 
format. 


For example, with an input of: 


This is described at 
<eref target="http://www.example.com/reports/r12.html"/>. 


An HTML formatter might generate: 
This is described at 


<a href="http://www.example.com/reports/r12.html"> 
http: //www.example.com/reports/r12.html</a>. 
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With an input of: 


This is described 
<eref target="http://www.example.com/reports/r12.html"> 
in this interesting report</eref>. 


An HTML formatter might generate: 


This is described 
<a href="http://www.example.com/reports/r12.html"> 
in this interesting report</a>. 


This element appears as a child element of <annotation> 

(Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <cref> 
(Section 2.16), <dd> (Section 2.18), <dt> (Section 2.21), <em> 
(Section 2.22), <li> (Section 2.29), <name> (Section 2.32), 
<postamble> (Section 3.5), <preamble> (Section 3.6), <strong> 
(Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t> 
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), <tt> 
(Section 2.62), and <ttcol> (Section 3.9). 


Content model: only text content. 

2.24.1. "target" Attribute (Mandatory) 
URI of the link target [RFC3986]. This must begin with a scheme name 
(such as "https://") and thus not be relative to the URL of the 


current document. 


2.25. <figure> 


Contains a figure with a caption with the figure number. If the 
element contains a <name> element, the caption will also show that 
name. 


This element appears as a child element of <aside> (Section 2.6), 
<blockquote> (Section 2.10), <dd> (Section 2.18), <li> 

(Section 2.29), <section> (Section 2.46), <td> (Section 2.56), and 
<th> (Section 2.58). 
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Content model: 


In this order: 


1. One optional <name> element (Section 2.32) 
2. Optional <iref> elements (Section 2.27) 
3. One optional <preamble> element (Section 3.6) 
4. In any order, but at least one of: 
*  <artwork> elements (Section 2.5) 
* <sourcecode> elements (Section 2.48) 
5. One optional <postamble> element (Section 3.5) 
2.25.1. "align" Attribute 
Deprecated. 


Note: does not affect title or <artwork> alignment. 


Allowed values: 


December 2016 


o "left" (default) 
o "center" 
o "right" 
2.25.2. "alt" Attribute 
Deprecated. If the goal is to provide a single URI for a reference, 


use the "target" attribute in <reference> instead. 


2.25.3. 


"anchor" Attribute 


Document-wide unique identifier for this figure. 


2.25.4. "height" Attribute 
Deprecated. 
Lili “sre” Attribute 
Deprecated. 
Hoffman Informational 
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2.25.6. "suppress-title" Attribute 
Deprecated. 
Allowed values: 
Oo. true" 
o "false" (default) 
2.25.7. "title" Attribute 
Deprecated. Use <name> instead. 
2.25.8. "width" Attribute 
Deprecated. 
2.26. <front> 


Represents the "front matter": metadata (such as author information), 
the Abstract, and additional notes. 


A <front> element may have more than one <seriesInfo> element. A 
<seriesInfo> element determines the document number (for RFCs) or 
name (for Internet-Drafts). Another <seriesInfo> element determines 
the "maturity level" (defined in [RFC2026]), using values of "std" 
for "Standards Track", "bcp" for "BCP", "info" for "Informational", 
"exp" for "Experimental", and "historic" for "Historic". The "name" 
attributes of those multiple <seriesInfo> elements interact as 
described in Section 2.47. 


This element appears as a child element of <reference> (Section 2.40) 
and <rfc> (Section 2.45). 


Content model: 


In this order: 


De One <title> element (Section 2.60) 

2. Optional <seriesInfo> elements (Section 2.47) 
Se One or more <author> elements (Section 2.7) 
4. One optional <date> element (Section 2.17) 

5. Optional <area> elements (Section 2.4) 
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6. Optional <workgroup> elements (Section 2.65) 

qe Optional <keyword> elements (Section 2.28) 

8. One optional <abstract> element (Section 2.1) 

9% Optional <note> elements (Section 2.33) 

10. One optional <boilerplate> element (Section 2.11) 


2.27. <iref> 
Provides terms for the document's index. 


Index entries can be either regular entries (when just the "item" 
attribute is given) or nested entries (by specifying "subitem" as 
well), grouped under a regular entry. 


Index entries generally refer to the exact place where the <iref> 
element occurred. An exception is the occurrence as a child element 
of <section>, in which case the whole section is considered to be 
relevant for that index entry. In some formats, index entries of 
this type might be displayed as ranges. 


When the prep tool is creating index content, it collects the items 
in a case-sensitive fashion for both the item and subitem level. 


This element appears as a child element of <annotation> 

(Section 2.3), <aside> (Section 2.6), <blockquote> (Section 2.10), 
<c> (Section 3.1), <dd> (Section 2.18), <dt> (Section 2.21), <em> 
(Section 2.22), <figure> (Section 2.25), <li> (Section 2.29), 
<postamble> (Section 3.5), <preamble> (Section 3.6), <section> 
(Section 2.46), <strong> (Section 2.50), <sub> (Section 2.51), <sup> 
(Section 2.52), <t> (Section 2.53), <table> (Section 2.54), <td> 
(Section 2.56), <th> (Section 2.58), <tt> (Section 2.62), and <ttcol> 
(Section 3.9). 


Content model: this element does not have any contents. 
2.27.1. "item" Attribute (Mandatory) 


The item to include. 
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2.27.2. "primary" Attribute 


Setting this to "true" declares the occurrence as "primary", which 
might cause it to be highlighted in the index. There is no 
restriction on the number of occurrences that can be "primary". 
Allowed values: 
o "true" 
o "false" (default) 

2.27.3. "subitem" Attribute 
The subitem to include. 

2.28. <keyword> 


Specifies a keyword applicable to the document. 


Note that each element should only contain a single keyword; for 
multiple keywords, the element can simply be repeated. 


Keywords are used both in the RFC Index and in the metadata of 
generated document representations. 


This element appears as a child element of <front> (Section 2.26). 
Content model: only text content. 

2229, SLIS 
A list element, used in <ol> and <ul>. 


This element appears as a child element of <ol> (Section 2.34) and 
<ul> (Section 2.63). 


Content model: 

Either: 
In any order, but at least one of: 
* <artwork> elements (Section 2.5) 
* <dl> elements (Section 2.20) 


* <figure> elements (Section 2.25) 
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2.29.1. 


Document-wide unique identifier for this list item. 


Hoffman 


The "xml2rfc" Version 3 Vocabulary 


<ol> elements (Section 2.34) 
<sourcecode> elements (Section 2.48) 
<t> elements (Section 2.53) 


<ul> elements (Section 2.63) 


any order, but at least one of: 
Text 

<bcp14> elements (Section 2.9) 
<cref> elements (Section 2.16) 
<em> elements (Section 2.22) 
<eref> elements (Section 2.24) 
<iref> elements (Section 2.27) 
<relref> elements (Section 2.44) 
<strong> elements (Section 2.50) 
<sub> elements (Section 2.51) 
<sup> elements (Section 2.52) 
<tt> elements (Section 2.62) 
<xref> elements (Section 2.66) 


"anchor" Attribute 


Informational 


December 2016 
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2.30. <link> 
A link to an external document that is related to the RFC. 


The following are the supported types of external documents that can 
be pointed to in a <link> element: 


o The current International Standard Serial Number (ISSN) for the 
RFC Series. The value for the "rel" attribute is "item". The 


link should use the form "urn:issn:". 


o The Digital Object Identifier (DOI) for this document. The value 


for the "rel" attribute is "describedBy". The link should use the 
form specified in [RFC7669]; this is expected to change in the 
future. 


o The Internet-Draft that was submitted to the RFC Editor to become 
the published RFC. The value for the "rel" attribute is 
"convertedFrom". The link should be to an IETF-controlled web 
site that retains copies of Internet-Drafts. 


o A representation of the document offered by the document author. 
The value for the "rel" attribute is "alternate". The link can be 
to a personally run web site. 

In RFC production mode, the prep tool needs to check the values for 

<link> before an RFC is published. In draft production mode, the 

prep tool might remove some <link> elements during the draft 
submission process. 

This element appears as a child element of <rfc> (Section 2.45). 

Content model: this element does not have any contents. 

2.30.1. "href" Attribute (Mandatory) 
The URI of the external document. 
2.30.2. "rel" Attribute 
The relationship of the external document to this one. The 


relationships are taken from the "Link Relations" registry maintained 
by IANA [LINKRELATIONS]. 
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2.31. <middle> 
Represents the main content of the document. 
This element appears as a child element of <rfc> (Section 2.45). 
Content model: 
One or more <section> elements (Section 2.46) 
2.32. <name> 
The name of the section, note, figure, or texttable. This name can 
indicate markup of flowing text (for example, including references or 
making some characters use a fixed-width font). 
This element appears as a child element of <figure> (Section 2.25), 
<note> (Section 2.33), <references> (Section 2.42), <section> 
(Section 2.46), <table> (Section 2.54), and <texttable> 
(Section 3.8). 
Content model: 
In any order: 
o Text 
o <cref> elements (Section 2.16) 
o <eref> elements (Section 2.24) 
o <relref> elements (Section 2.44) 
o <tt> elements (Section 2.62) 
o <xref> elements (Section 2.66) 


2.33. <note> 


Creates an unnumbered, titled block of text that appears after the 
Abstract. 


It is usually used for additional information to reviewers (Working 
Group information, mailing list, ...) or for additional publication 


information such as "IESG Notes". 


This element appears as a child element of <front> (Section 2.26). 
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Content model: 
In this order: 
1. One optional <name> element (Section 2.32) 
2. In any order, but at least one of: 
* <dl> elements (Section 2.20) 
* <ol> elements (Section 2.34) 
* <t> elements (Section 2.53) 
* <ul> elements (Section 2.63) 
2.33.1. “removeInRFC" Attribute 
If set to "true", this note is marked in the prep tool with text 
indicating that it should be removed before the document is published 
as an RFC. That text will be "This note is to be removed before 
publishing as an RFC." 
Allowed values: 
o "true" 
o "false" (default) 
2.33.2. "title" Attribute 
Deprecated. Use <name> instead. 
2.34. <ol> 


An ordered list. The labels on the items will be either a number or 
a letter, depending on the value of the style attribute. 


This element appears as a child element of <abstract> (Section 2.1), 
<aside> (Section 2.6), <blockquote> (Section 2.10), <dd> 

(Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section> 
(Section 2.46), <td> (Section 2.56), and <th> (Section 2.58). 


Content model: 


One or more <li> elements (Section 2.29) 
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2.34.1. "anchor" Attribute 
Document-wide unique identifier for the list. 
2.34.2. "group" Attribute 


When the prep tool sees an <ol> element with a "group" attribute that 
has already been seen, it continues the numbering of the list from 
where the previous list with the same group name left off. If an 
<ol> element has both a "group" attribute and a "start" attribute, 
the group's numbering is reset to the given start value. 


2.34.3. "spacing" Attribute 


Defines whether or not there is a blank line between entries. 
spacing="normal" indicates a single blank line, while 
spacing="compact" indicates no space between. 


Allowed values: 


o "normal" (default) 
o "compact" 
2.34.4. "start" Attribute 


The ordinal value at which to start the list. This defaults to "1" 
and must be an integer of 0 or greater. 


2.34.5. "type" Attribute 


The type of the labels on list items. If the length of the type 
value is 1, the meaning is the same as it is for HTML: 


a Lowercase letters (a, b, c, ...) 

A Uppercase letters (A, B, C, ...) 

1 Decimal numbers (1, 2, 3, ...) 

i Lowercase Roman numerals (i, ii, iii, ...) 
I Uppercase Roman numerals (I, II, III, ...) 


For types "a" and "A", after the 26th entry, the numbering starts at 
"aa"/"AA", then "ab"/"AB", and so on. 
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If the length of the type value is greater than 1, the value must 
contain a percent-encoded indicator and other text. The value is a 
free-form text that allows counter values to be inserted using a 
"percent-letter" format. For instance, "[REQ%d]" generates labels of 
the form "[REQ1]", where "%d" inserts the item number as a decimal 
number. 

The following formats are supported: 

sc Lowercase letters (a, b, C, ...) 

SC Uppercase letters (A, B, C, ...) 

$d Decimal numbers (1, 2, 3, ...) 

$i Lowercase Roman numerals (i, ii, iii, ...) 

SI Uppercase Roman numerals (I, II, III, ...) 


%% Represents a percent sign 


Other formats are reserved for future use. Only one percent encoding 
other than "%%" is allowed in a type string. 


It is an error for the type string to be empty. For bulleted lists, 
use the <ul> element. For lists that have neither bullets nor 


numbers, use the <ul> element with the ’empty="true"’ attribute. 


If no type attribute is given, the default type is the same as 
"type='Sd.'". 


2.35. <organization> 
Specifies the affiliation [RFC7322] of an author. 


This information appears both in the "Author’s Address" section and 


on the front page (see [RFC7322] for more information). If the value 
is long, an abbreviated variant can be specified in the "abbrev" 
attribute. 


This element appears as a child element of <author> (Section 2.7). 
Content model: only text content. 
2.35.1. "abbrev" Attribute 


Abbreviated variant. 
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2.35.2. "ascii" Attribute 

The ASCII equivalent of the organization’s name. 
2.36. <phone> 

Represents a phone number. 


The value is expected to be the scheme-specific part of a "tel" URI 


(and so does not include the prefix "tel:"), using the 
"global-number-digits" syntax. See Section 3 of [RFC3966] for 
details. 


This element appears as a child element of <address> (Section 2.2). 
Content model: only text content. 
2.37. <postal> 

Contains optional child elements providing postal information. These 
elements will be displayed in an order that is specific to 
formatters. A postal address can contain only a set of <street>, 
<city>, <region>, <code>, and <country> elements, or only an ordered 
set of <postalline> elements, but not both. 
This element appears as a child element of <address> (Section 2.2). 
Content model: 
Either: 

In any order: 

* <city> elements (Section 2.13) 

* <code> elements (Section 2.14) 

* <country> elements (Section 2.15) 


* <region> elements (Section 2.43) 


* <street> elements (Section 2.49) 


One or more <postalLine> elements (Section 2.38) 
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2.38. <postalLine> 


Represents one line of a postal address. When more than one 
<postalLine> is given, the prep tool emits them in the order given. 


This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 
2.38.1. "ascii" Attribute 
The ASCII equivalent of the text in the address line. 
2.39. <refcontent> 
Text that should appear between the title and the date of a 


reference. The purpose of this element is to prevent the need to 
abuse <seriesInfo> to get such text in a reference. 


For example: 
<reference anchor="Aprill"> 
<front> 
<title>On Being A Fool</title> 
<author initials="K." surname="Phunny" fullname="Knot Phunny"/> 
<date year="2000" month="April"/> 
</front> 
<refcontent>Self-published pamphlet</refcontent> 
</reference> 
would render as: 


[Apri11] Phunny, K., "On Being A Fool", Self-published 
pamphlet, April 2000. 


This element appears as a child element of <reference> 
(Section 2.40). 


Content model: 

In any order: 

o Text 

o  <bcp14> elements (Section 2.9) 


o <em> elements (Section 2.22) 
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o <strong> elements (Section 2.50) 
o <sub> elements (Section 2.51) 
o <sup> elements (Section 2.52) 
o <tt> elements (Section 2.62) 
2.40. <reference> 
Represents a bibliographic reference. 


This element appears as a child element of <referencegroup> 
(Section 2.41) and <references> (Section 2.42). 


Content model: 

In this order: 

1. One <front> element (Section 2.26) 

2. In any order: 
* <annotation> elements (Section 2.3) 
* <format> elements (Section 3.3) 
*  <refcontent> elements (Section 2.39) 


* <seriesInfo> elements (Section 2.47; deprecated in this 
context) 


2.40.1. "anchor" Attribute (Mandatory) 
Document-wide unique identifier for this reference. Usually, this 
will be used both to "label" the reference in the "References" 
section and as an identifier in links to this reference entry. 


2.40.2. "quoteTitle" Attribute 


Specifies whether or not the title in the reference should be quoted. 
This can be used to prevent quoting, such as on errata. 


Allowed values: 
o "true" (default) 


o "false" 
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2.40.3. "target" Attribute 
Holds the URI for the reference. 

2.41. <referencegroup> 
Represents a list of bibliographic references that will be 
represented as a single reference. This is most often used to 
reference STDs and BCPs, where a single reference (such as "BCP 9") 


may encompass more than one RFC. 


This element appears as a child element of <references> 
(Section 2.42). 


Content model: 
One or more <reference> elements (Section 2.40) 
2.41.1. "anchor" Attribute (Mandatory) 
Document-wide unique identifier for this reference group. Usually, 
this will be used both to "label" the reference group in the 


"References" section and as an identifier in links to this reference 
entry. 


2.42. <references> 
Contains a set of bibliographic references. 


In the early days of the RFC Series, there was only one "References" 
section per RFC. This convention was later changed to group 
references into two sets, "Normative" and "Informative", as described 
in [RFC7322]. This vocabulary supports the split with the <name> 
child element. In general, the title should be either "Normative 
References" or "Informative References". 


This element appears as a child element of <back> (Section 2.8). 
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Content model: 
In this order: 
1. One optional <name> element (Section 2.32) 
2. In any order: 
* <reference> elements (Section 2.40) 
* <referencegroup> elements (Section 2.41) 
2.42.1. "anchor" Attribute 
An optional user-supplied identifier for this set of references. 
2.42.2. "title" Attribute 
Deprecated. Use <name> instead. 
2.43. <region> 
Provides the region name in a postal address. 
This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 
2.43.1. "ascii" Attribute 
The ASCII equivalent of the region name. 
2.44. <relref> 
Represents a link to a specific part of a document that appears ina 
<reference> element. Formatters that have links (such as HTML and 
PDF) render <relref> elements as external hyperlinks to the specified 
part of the reference, creating the link target by combining the base 
URI from the <reference> element with the "relative" attribute from 


this element. The "target" attribute is required, and it must be the 
anchor of a <reference> element. 


The "section" attribute is required, and the "relative" attribute is 
optional. If the reference is not an RFC or Internet-Draft that is 

in the v3 format, the element needs to have a "relative" attribute; 

in this case, the value of the "Section" attribute is ignored. 
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An example of the <relref> element with text content might be: 


See 

<relref section="2.3" target="RFC9999" displayFormat="bare"> 
the protocol overview</relref> 

for more information. 


An HTML formatter might generate: 


See 

<a href="http://www.rfc-editor.org/rfc/rfc9999.htmlts-2.3"> 
the protocol overview</a> 

for more information. 


Note that the URL in the above example might be different when the 
RFC Editor deploys the v3 format. 


This element appears as a child element of <annotation> 

(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <name> (Section 2.32), <preamble> (Section 3.6), 
<strong> (Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), 
<t> (Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and 
<tt> (Section 2.62). 


Content model: only text content. 
2.44.1. "displayFormat" Attribute 


This attribute is used to signal formatters what the desired format 
of the relative reference should be. Formatters for document types 
that have linking capability should wrap each part of the displayed 
text in hyperlinks. If there is content in the <relref> element, 
formatters will ignore the value of this attribute. 


taf” 
A formatter should display the relative reference as the word 
"Section" followed by a space, the contents of the "section" 
attribute followed by a space, the word "of", another space, and 
the value from the "target" attribute enclosed in square brackets. 
For example, with an input of: 
See 


<relref section="2.3" target="RFC9999" displayFormat="of"/> 
for an overview. 
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An HTML formatter might generate: 


See 


<a href="http://www.rfc-editor.org/info/rfc9999%fs-2.3"> 
Section 2.3</a> of 


[<a href="fREC9999">RFC9999</a>] 
for an overview. 


Note that "displayFormat=’of’" is the default for <relref>, so it 


does not need to be given in a <relref> element if that format is 
desired. 


"comma" 


A formatter should display the relative reference as the value 
from the "target" attribute enclosed in square brackets, a comma, 


a space, the word "Section" followed by a space, and the "section" 
attribute. 


For example, with an input of: 


See 


<relref section="2.3" target="RFC9999" displayFormat="comma"/>, 
for an overview. 


An HTML formatter might generate: 


See 
[<a href="fREC9I999">RFC9999</a>], 


<a href="http://www.rfc-editor.org/info/rfc9999%fs-2.3"> 
Section 2.3</a>, for an overview. 


"parens" 


A formatter should display the relative reference as the value 
from the "target" attribute enclosed in square brackets, a space, 
a left parenthesis, the word "Section" followed by a space, the 
"section" attribute, and a right parenthesis. 


For example, with an input of: 
See 


<relref section="2.3" target="RFC9999" displayFormat="parens"/> 
for an overview. 
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An HTML formatter might generate: 


See 

[<a href="#RFC9999">RFC9999</a>] 

(<a href="http://www.rfc-editor.org/info/rfc9999%fs-2.3"> 
Section 2.3</a>) 

for an overview. 


"bare" 
A formatter should display the relative reference as the contents 


of the "section" attribute and nothing else. This is useful when 
there are multiple relative references to a single base reference. 


For example: 


See Sections 

<relref section="2.3" target="RFC9999" displayFormat="bare"/> 
and 

<relref section="2.4" target="RFC9999" displayFormat="of"/> 
for an overview. 


An HTML formatter might generate: 


See Sections 

<a href="http://www.rfc-editor.org/info/rfc9999%fs-2.3"> 
2.3</a> 

and 

<a href="http://www.rfc-editor.org/info/rfc9999#s-2.4"> 
Section 2.4</a> of 

[<a href="#RFC9I999">RFC9999</a>] 

for an overview. 


Allowed values: 


o "of" (default) 


o "comma" 
o "parens" 
o "bare" 
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2.44.2. "relative" Attribute 


Specifies a relative reference from the URI in the target reference. 
This value must include whatever leading character is needed to 
create the relative reference; typically, this is "#" for HTML 


documents. 
2.44.3. "section" Attribute (Mandatory) 
Specifies a section of the target reference. If the reference is not 


an RFC or Internet-Draft in the v3 format, it is an error. 


2.44.4. "target" Attribute (Mandatory) 
The anchor of the reference for this element. If this value is not 
an anchor to a <reference> or <referencegroup> element, it is an 
error. If the reference at the target has no URI, it is an error. 


2.45. <rfc> 
This is the root element of the xml2rfc vocabulary. 
Content model: 
In this order: 


1. Optional <link> elements (Section 2.30) 


2. One <front> element (Section 2.26) 

3. One <middle> element (Section 2.31) 

4. One optional <back> element (Section 2.8) 
2.45.1. "category" Attribute 


Deprecated; instead, use the "name" attribute in <seriesInfo>. 
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2.45.2. "consensus" Attribute 
Affects the generated boilerplate. Note that the values of "no" and 
"yes" are deprecated and are replaced by "false" (the default) and 
"truet, 


See [RFC7841] for more information. 


Allowed values: 


o "yes" 
o "false" (default) 
o "true" 
2.45.3. "docName" Attribute 
Deprecated; instead, use the "value" attribute in <seriesInfo>. 
2.45.4. “indexInclude" Attribute 
Specifies whether or not a formatter is requested to include an index 
in generated files. If the source file has no <iref> elements, an 
index is never generated. This option is useful for generating 


documents where the source document has <iref> elements but the 
author no longer wants an index. 


Allowed values: 


o "true" (default) 


o "false" 
2.45.5. "ipr" Attribute 
Represents the Intellectual Property status of the document. See 


Appendix A.1 for details. 
2.45.6. "iprExtract" Attribute 
Identifies a single section within the document for which extraction 


"as is" is explicitly allowed (only relevant for historic values of 
the "ipr" attribute). 
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2.45.7. "number" Attribute 

Deprecated; instead, use the "value" attribute in <seriesInfo>. 
2.45.8. "obsoletes" Attribute 

A comma-separated list of RFC numbers or Internet-Draft names. 


The prep tool will parse the attribute value so that incorrect 
references can be detected. 


2.45.9. "prepTime" Attribute 
The date that the XML was processed by a prep tool. This is included 
in the XML file just before it is saved to disk. The value is 
formatted using the "date-time" format defined in Section 5.6 of 
[RFC3339]. The "time-offset" should be "z". 

2.45.10. "seriesNo" Attribute 
Deprecated; instead, use the "value" attribute in <seriesInfo>. 


2.45.11. "sortRefs" Attribute 


Specifies whether or not the prep tool will sort the references in 
each reference section. 


Allowed values: 
o "true" 
o "false" (default) 
2.45.12. "submissionType" Attribute 


The document stream, as described in [RFC7841]. (The RFC Series 
Editor may change the list of allowed values in the future.) 


Allowed values: 


o "IETF" (default) 


O " IAB " 
o "IRTE" 
o "independent" 
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2.45.13. "symRefs" Attribute 
Specifies whether or not a formatter is requested to use symbolic 
references (such as "[RFC2119]"). If the value for this is "false", 
the references come out as numbers (such as "[3]"). 


Allowed values: 
o "true" (default) 
o "false" 
2.45.14. "tocDepth" Attribute 


Specifies the number of levels of headings that a formatter is 
requested to include in the table of contents; the default is "3". 


2.45215. "tocInclude" Attribute 


Specifies whether or not a formatter is requested to include a table 
of contents in generated files. 


Allowed values: 
o "true" (default) 
o "false" 
2.45.16. "updates" Attribute 
A comma-separated list of RFC numbers or Internet-Draft names. 


The prep tool will parse the attribute value so that incorrect 
references Can be detected. 


2.45.17. "version" Attribute 


Specifies the version of xml2rfc syntax used in this document. The 
only expected value (for now) is "3". 


2.46. <section> 


Represents a section (when inside a <middle> element) or an appendix 
(when inside a <back> element). 


Subsections are created by nesting <section> elements inside 
<section> elements. Sections are allowed to be empty. 
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This element appears as a child element of <back> (Section 2.8), 
<boilerplate> (Section 2.11), <middle> (Section 2.31), and <section> 
(Section 2.46). 


Content model: 


In this order: 


1. One optional <name> element (Section 2.32) 


2. In any order: 


* 


<artwork> elements (Section 2.5) 
<aside> elements (Section 2.6) 
<blockquote> elements (Section 2.10) 
<dl> elements (Section 2.20) 
<figure> elements (Section 2.25) 
<iref> elements (Section 2.27) 

<ol> elements (Section 2.34) 
<sourcecode> elements (Section 2.48) 
<t> elements (Section 2.53) 

<table> elements (Section 2.54) 
<texttable> elements (Section 3.8) 


<ul> elements (Section 2.63) 


3. Optional <section> elements (Section 2.46) 


2.46.1. 


"anchor" Attribute 


Document-wide unique identifier for this section. 


2.46.2. 


"numbered" Attribute 


If set to "false", the formatter is requested to not display a 
section number. The prep tool will verify that such a section is not 
followed by a numbered section in this part of the document and will 
verify that the section is a top-level section. 
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Allowed values: 
o "true" (default) 
o "false" 
2.46.3. “removeInRFC" Attribute 
If set to "true", this note is marked in the prep tool with text 
indicating that it should be removed before the document is published 


as an RFC. That text will be "This note is to be removed before 
publishing as an RFC." 


Allowed values: 
o "true" 
o "false" (default) 

2.46.4. "title" Attribute 
Deprecated. Use <name> instead. 

2.46.5. "toc" Attribute 
Indicates to a formatter whether or not the section is to be included 
in a table of contents, if such a table of contents is produced. 
This only takes effect if the level of the section would have 
appeared in the table of contents based on the "tocDepth" attribute 
of the <rfc> element, and of course only if the table of contents is 
being created based on the "tocInclude" attribute of the <rfc> 
element. If this is set to "exclude", any section below this one 
will be excluded as well. The "default" value indicates inclusion of 
the section if it would be included by the tocDepth attribute of the 
<rfc> element. 
Allowed values: 
o "include" 


o "exclude" 


o "default" (default) 
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2.47. <seriesInfo> 


Specifies the document series in which this document appears, and 
also specifies an identifier within that series. 


A processing tool determines whether it is working on an RFC or an 
Internet-Draft by inspecting the "name" attribute of a <seriesInfo> 
element inside the <front> element inside the <rfc> element, looking 
for "RFC" or "Internet-Draft". (Specifying neither value in any of 
the <seriesInfo> elements can be useful for producing other types of 
documents but is out of scope for this specification.) 


It is invalid to have multiple <seriesInfo> elements inside the same 
<front> element containing the same "name" value. Some combinations 
of <seriesInfo> "name" attribute values make no sense, such as having 
both <seriesInfo name="rfc"/> and <seriesInfo name="Internet-Draft"/> 
in the same <front> element. 


This element appears as a child element of <front> (Section 2.26) and 
<reference> (Section 2.40; deprecated in this context). 


Content model: this element does not have any contents. 
2.47.1. “asciiName" Attribute 

The ASCII equivalent of the name field. 
2.47.2. “asciiValue" Attribute 


The ASCII equivalent of the value field. 


2.47.3. "name" Attribute (Mandatory) 
The name of the series. The currently known values are "RFC", 
"Internet-Draft", and "DOI". The RFC Series Editor may change this 


list in the future. 
Some of the values for "name" interact as follows: 


o If a <front> element contains a <seriesInfo> element with a name 
of "Internet-Draft", it can also have at most one additional 
<seriesInfo> element with a "status" attribute whose value is of 
"standard", "full-standard", "bcp", "fyi", "informational", 
"experimental", or "historic" to indicate the intended status of 
this Internet-Draft, if it were to be later published as an RFC. 
If such an additional <seriesInfo> element has one of those 
statuses, the name needs to be "". 


Hoffman Informational [Page 57] 


RFC 7991 The "xml2rfc" Version 3 Vocabulary December 2016 


o 


If a <front> element contains a <seriesInfo> element with a name 
of "RFC", it can also have at most one additional <seriesInfo> 
element with a "status" attribute whose value is of 
"full-standard", "bcp", or "fyi" to indicate the current status of 
this REC. If such an additional <seriesInfo> element has one of 
those statuses, the "value" attribute for that name needs to be 
the number within that series. That <front> element might also 
contain an additional <seriesInfo> element with the status of 
"info", "exp", or "historic" and a name of "" to indicate the 
status of the RFC. 


A <front> element that has a <seriesInfo> element that has the 
name "Internet-Draft" cannot also have a <seriesInfo> element that 
has the name "RFC". 


The <seriesInfo> element can contain the DOI for the referenced 
document. This cannot be used when the <seriesInfo> element is an 
eventual child element of an <rfc> element -- only as an eventual 
child of a <reference> element. The "value" attribute should use 
the form specified in [RFC7669]. 


2.47.4. "status" Attribute 


The status of this document. The currently known values are 
"standard", "informational", "experimental", "bcp", "fyi", and 
"full-standard". The RFC Series Editor may change this list in the 
future. 


2.47.5. "stream" Attribute 


The stream (as described in [RFC7841]) that originated the document. 
(The RFC Series Editor may change this list in the future.) 


Allowed values: 


o 


"IETF" (default) 
" TAB " 
"IRTE" 


"independent" 
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2.47.6. "value" Attribute (Mandatory) 
The identifier within the series specified by the "name" attribute. 


For BCPs, FYIs, RFCs, and STDs, this is the number within the series. 
For Internet-Drafts, it is the full draft name (ending with the 
two-digit version number). For DOIs, the value is given, such as 
"10.17487/rfc1149", as described in [RFC7669]. 


The name in the value should be the document name without any file 
extension. For Internet-Drafts, the value for this attribute should 
be "draft-ietf-somewg-someprotocol-0O7", not 
"draft-ietf-somewg-someprotocol-07.txt". 


2.48. <sourcecode> 
This element allows the inclusion of source code into the document. 


When rendered, source code is always shown in a monospace font. When 
<sourcecode> is a child of <figure> or <section>, it provides full 
control of horizontal whitespace and line breaks. When formatted, it 
is indented relative to the left margin of the enclosing element. It 
is thus useful for source code and formal languages (such as ABNF 
[RFC5234] or the RNC notation used in this document). (When 
<sourcecode> is a child of other elements, it flows with the text 
that surrounds it.) Tab characters (U+0009) inside of this element 
are prohibited. 


For artwork such as character-based art, diagrams of message layouts, 
and so on, use the <artwork> element instead. 


Output formatters that do pagination should attempt to keep source 
code on a single page. This is to prevent source code that is split 


across pages from looking like two separate pieces of code. 


See Section 5 for a description of how to deal with issues of using 
"E" and "<" characters in source code. 


This element appears as a child element of <blockquote> 

(Section 2.10), <dd> (Section 2.18), <figure> (Section 2.25), <li> 
(Section 2.29), <section> (Section 2.46), <td> (Section 2.56), and 
<th> (Section 2.58). 

Content model: only text content. 


2.48.1. "anchor" Attribute 


Document-wide unique identifier for this source code. 
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2.48.2. "name" Attribute 


A filename suitable for the contents (such as for extraction to a 
local file). This attribute can be helpful for other kinds of tools 
(such as automated syntax checkers, which work by extracting the 
source code). Note that the "name" attribute does not need to be 
unique for <artwork> elements in a document. If multiple 
<sourcecode> elements have the same "name" attribute, a formatter 
might assume that the elements are all fragments of a single file, 
and such a formatter can collect those fragments for later 
processing. 


2.48.3: "src" Attribute 
The URI reference of a source file [RFC3986]. 


It is an error to have both a "src" attribute and content in the 
<sourcecode> element. 


2.48.4. "type" Attribute 


Specifies the type of the source code. The value of this attribute 
is free text with certain values designated as preferred. 


The preferred values for <sourcecode> types are: 
o abnf 


o asn.l 


o bash 
o c++ 
Oo “e 

o cbor 
o dtd 
o Java 


o Javascript 
o json 


o mib 
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o perl 


o pseudocode 


o python 
o rnc 

o xml 

o yang 


The RFC Series Editor will maintain a complete list of the preferred 
values on the RFC Editor web site, and that list is expected to be 


updated over time. Thus, a consumer of v3 XML should not cause a 
failure when it encounters an unexpected type or no type is 
specified. 


2.49. <street> 
Provides a street address. 
This element appears as a child element of <postal> (Section 2.37). 
Content model: only text content. 

2.49.1. "ascii" Attribute 
The ASCII equivalent of the street address. 

2.50. <strong> 
Indicates text that is semantically strong. Text enclosed within 
this element will be displayed as bold after processing. This 
element can be combined with other character formatting elements, and 
the formatting will be additive. 
This element appears as a child element of <annotation> 
(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <preamble> (Section 3.6), <refcontent> 
Section 2.39), <sub> (Section 2.51), <sup> (Section 2.52), <t> 


) 
( ) 
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), and <tt> 
(Section 2.62) 
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Lois 


Content model: 

In any order: 

o Text 

o <bcp14> elements (Section 2.9) 
o <cref> elements (Section 2.16) 
o <em> elements (Section 2.22) 

o <eref> elements (Section 2.24) 
o <iref> elements (Section 2.27) 
o <relref> elements (Section 2.44) 
o <sub> elements (Section 2.51) 
o <sup> elements (Section 2.52) 
o <tt> elements (Section 2.62) 


o <xref> elements (Section 2.66) 


51. <sub> 


Causes the text to be displayed as subscript, approximately half a 
letter-height lower than normal text. This element can be combined 
with other character formatting elements, and the formatting will be 
additive. 


This element appears as a child element of <annotation> 

(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <preamble> (Section 3.6), <refcontent> 

(Section 2.39), <strong> (Section 2.50), <t> (Section 2.53), <td> 
(Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62). 
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Za 


Content model: 

In any order: 

o Text 

o <bcp14> elements (Section 2.9) 

o <cref> elements (Section 2.16) 

o <em> elements (Section 2.22) 

o <eref> elements (Section 2.24) 

o <iref> elements (Section 2.27) 

o <relref> elements (Section 2.44) 
o <strong> elements (Section 2.50) 
o <tt> elements (Section 2.62) 


o <xref> elements (Section 2.66) 


52. <sup> 


Causes the text to be displayed as superscript, approximately half a 
letter-height higher than normal text. This element can be combined 
with other character formatting elements, and the formatting will be 
additive. 


This element appears as a child element of <annotation> 

(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <preamble> (Section 3.6), <refcontent> 

(Section 2.39), <strong> (Section 2.50), <t> (Section 2.53), <td> 
(Section 2.56), <th> (Section 2.58), and <tt> (Section 2.62). 
Content model: 

In any order: 

o Text 


o <bcp14> elements (Section 2.9) 


o <cref> elements (Section 2.16) 
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2:93) 


<em> elements (Section 2.22) 
<eref> elements (Section 2.24) 
<iref> elements (Section 2.27) 
<relref> elements (Section 2.44) 
<strong> elements (Section 2.50) 
<tt> elements (Section 2.62) 
<xref> elements (Section 2.66) 


<t> 


Contains a paragraph of text. 


The "xml2rfc" Version 3 Vocabulary 


December 2016 


This element appears as a child element of <abstract> (Section 2.1), 


<aside> (Section 2.6), <blockquote> 
(Section 2.18), <li> (Section 2.29), 
(Section 2.33), <section> (Section 2.46), 


<th> (Section 2.58). 


Content model: 


In any order: 


o Text 

o <bcp14> elements (Section 2.9) 

o <cref> elements (Section 2.16) 

o <em> elements (Section 2.22) 

o <eref> elements (Section 2.24) 

o <iref> elements (Section 2.27) 

o <list> elements (Section 3.4) 

o <relref> elements (Section 2.44) 

o <spanx> elements (Section 3.7) 

o <strong> elements (Section 2.50) 
Hoffman 


<list> 


Informational 


<td> 
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o <sub> elements (Section 2.51) 

o <sup> elements (Section 2.52) 

o <tt> elements (Section 2.62) 

o <vspace> elements (Section 3.10) 

o <xref> elements (Section 2.66) 
2.53.1. "anchor" Attribute 


Document-wide unique identifier for this paragraph. 


2.53.2. "hangText" Attribute 
Deprecated. Instead, use <dd> inside of a definition list (<dl>). 
2.53.3. "keepWithNext" Attribute 


Acts as a hint to the output formatters that do pagination to doa 
best-effort attempt to keep the paragraph with the next element, 
whatever that happens to be. For example, the HTML output @media 
print CSS ("CSS" refers to Cascading Style Sheets) might translate 
this to page-break-after: avoid. For PDF, the paginator could 
attempt to keep the paragraph with the next element. Note: this 
attribute is strictly a hint and not always actionable. 


Allowed values: 
o "false" (default) 
o "true" 
2.53.4. "keepWithPrevious" Attribute 


Acts as a hint to the output formatters that do pagination to doa 
best-effort attempt to keep the paragraph with the previous element, 
whatever that happens to be. For example, the HTML output @media 
print CSS might translate this to page-break-before: avoid. For PDF, 
the paginator could attempt to keep the paragraph with the previous 
element. Note: this attribute is strictly a hint and not always 
actionable. 
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Allowed values: 
o "false" (default) 
o "true" 


2.54. <table> 


Contains a table with a caption with the table number. If the 
element contains a <name> element, the caption will also show that 
name. 


Inside the <table> element is, optionally, a <thead> element to 
contain the rows that will be the table's heading and, optionally, a 
<tfoot> element to contain the rows of the table's footer. If the 
XML is converted to a representation that has page breaks (such as 
PDFs or printed HTML), the header and footer are meant to appear on 
each page. 


This element appears as a child element of <aside> (Section 2.6) and 
<section> (Section 2.46). 


Content model: 

In this order: 

1. One optional <name> element (Section 2.32) 
2. Optional <iref> elements (Section 2.27) 


3. One optional <thead> element (Section 2.59) 


4. One or more <tbody> elements (Section 2.55) 
5. One optional <tfoot> element (Section 2.57) 
2.54.1. "anchor" Attribute 


Document-wide unique identifier for this table. 
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2.55. <tbody> 
A container for a set of body rows for a table. 
This element appears as a child element of <table> (Section 2.54). 
Content model: 
One or more <tr> elements (Section 2.61) 
2.55.1. "anchor" Attribute 
Document-wide unique identifier for the tbody. 
2.56. <td> 
A cell in a table row. 
This element appears as a child element of <tr> (Section 2.61). 
Content model: 
Either: 
In any order, but at least one of: 
* <artwork> elements (Section 2.5) 
* <dl> elements (Section 2.20) 
* <figure> elements (Section 2.25) 
* <ol> elements (Section 2.34) 
* <sourcecode> elements (Section 2.48) 
* <t> elements (Section 2.53) 


* <ul> elements (Section 2.63) 
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In any order: 

* Text 

* <bcp14> elements (Section 2.9) 

* <br> elements (Section 2.12) 

* <cref> elements (Section 2.16) 

* <em> elements (Section 2.22) 

* <eref> elements (Section 2.24) 

* <iref> elements (Section 2.27) 

* <relref> elements (Section 2.44) 

* <strong> elements (Section 2.50) 

* <sub> elements (Section 2.51) 

* <sup> elements (Section 2.52) 

* <tt> elements (Section 2.62) 

* <xref> elements (Section 2.66) 

2.56.1. "align" Attribute 

Controls whether the content of the cell appears left justified 
(default), centered, or right justified. Note that "center" or 
"right" will probably only work well in cells with plain text; any 
other elements might make the contents render badly. 


Allowed values: 


o "left" (default) 


o "center" 
o "right" 
2256.2% "anchor" Attribute 


Document-wide unique identifier for the cell. 
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2.56.3. "colspan" Attribute 
The number of columns that the cell is to span. For example, setting 
"colspan=’ 3’" indicates that the cell occupies the same horizontal 
space as three cells of a row without any "colspan" attributes. 
2.56.4. "rowspan" Attribute 
The number of rows that the cell is to span. For example, setting 
"rowspan="3'" indicates that the cell occupies the same vertical 
space as three rows. 
2.57. <tfoot> 
A container for a set of footer rows for a table. 
This element appears as a child element of <table> (Section 2.54). 
Content model: 
One or more <tr> elements (Section 2.61) 
2.57.1. "anchor" Attribute 
Document-wide unique identifier for the tfoot. 
2.58. <th> 
A cell in a table row. When rendered, this will normally come out in 
boldface; other than that, there is no difference between this and 
the <td> element. 
This element appears as a child element of <tr> (Section 2.61). 
Content model: 
Either: 
In any order, but at least one of: 
* <artwork> elements (Section 2.5) 
* <dl> elements (Section 2.20) 


* <figure> elements (Section 2.25) 


* <ol> elements (Section 2.34) 
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* <sourcecode> elements (Section 2.48) 
* <t> elements (Section 2.53) 


* <ul> elements (Section 2.63) 


In any order: 
* Text 
* <bcp14> elements (Section 2.9) 
* <br> elements (Section 2.12) 
* <cref> elements (Section 2.16) 
* <em> elements (Section 2.22) 
* <eref> elements (Section 2.24) 
* <iref> elements (Section 2.27) 
* <relref> elements (Section 2.44) 
* <strong> elements (Section 2.50) 
* <sub> elements (Section 2.51) 
* <sup> elements (Section 2.52) 
* <tt> elements (Section 2.62) 
* <xref> elements (Section 2.66) 
2.58.1. "align" Attribute 
Controls whether the content of the cell appears left justified 
(default), centered, or right justified. Note that "center" or 


"right" will probably only work well in cells with plain text; any 
other elements might make the contents render badly. 
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Allowed values: 


o "left" (default) 


o "center" 
o "right" 
2498:27 "anchor" Attribute 


Document-wide unique identifier for the row. 
2.58.3. "colspan" Attribute 
The number of columns that the cell is to span. For example, setting 
"colspan='3'" indicates that the cell occupies the same horizontal 
space as three cells of a row without any "colspan" attributes. 
2.58.4. "rowspan" Attribute 
The number of rows that the cell is to span. For example, setting 
"rowspan='3'" indicates that the cell occupies the same vertical 
space as three rows. 
2.59. <thead> 
A container for a set of header rows for a table. 
This element appears as a child element of <table> (Section 2.54). 
Content model: 
One or more <tr> elements (Section 2.61) 


2.59.1. "anchor" Attribute 


Document-wide unique identifier for the thead. 
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2.60. <title> 
Represents the document title. 
When this element appears in the <front> element of the current 
document, the title might also appear in page headers or footers. If 
it is long ("40 characters), the "abbrev" attribute can be used to 
specify an abbreviated variant. 
This element appears as a child element of <front> (Section 2.26). 
Content model: only text content. 

2.60.1. "abbrev" Attribute 
Specifies an abbreviated variant of the document title. 

2.60.2. "ascii" Attribute 
The ASCII equivalent of the title. 

2.61. <tr> 


A row of a table. 


This element appears as a child element of <tbody> (Section 2.55), 
<tfoot> (Section 2.57), and <thead> (Section 2.59). 


Content model: 

In any order, but at least one of: 

o <td> elements (Section 2.56) 

o <th> elements (Section 2.58) 
2.61.1. "anchor" Attribute 


Document-wide unique identifier for the row. 
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2.62. <tt> 
Causes the text to be displayed in a constant-width font. This 
element can be combined with other character formatting elements, and 
the formatting will be additive. 
This element appears as a child element of <annotation> 
(Section 2.3), <blockquote> (Section 2.10), <cref> (Section 2.16), 
<dd> (Section 2.18), <dt> (Section 2.21), <em> (Section 2.22), <li> 
(Section 2.29), <name> (Section 2.32), <preamble> (Section 3.6), 
<refcontent> (Section 2.39), <strong> (Section 2.50), <sub> 
(Section 2.51), <sup> (Section 2.52), <t> (Section 2.53), <td> 
(Section 2.56), and <th> (Section 2.58). 
Content model: 
In any order: 
o Text 
o  <bcp14> elements (Section 2.9) 
o <cref> elements (Section 2.16) 
o <em> elements (Section 2.22) 
o <eref> elements (Section 2.24) 
o <iref> elements (Section 2.27) 
o <relref> elements (Section 2.44) 
o <strong> elements (Section 2.50) 
o <sub> elements (Section 2.51) 


o <sup> elements (Section 2.52) 


o <xref> elements (Section 2.66) 
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2.63. <ul> 


An unordered list. The labels on the items will be symbols picked by 
the formatter. 


This element appears as a child element of <abstract> (Section 2.1), 
<aside> (Section 2.6), <blockquote> (Section 2.10), <dd> 
(Section 2.18), <li> (Section 2.29), <note> (Section 2.33), <section> 
(Section 2.46), <td> (Section 2.56), and <th> (Section 2.58). 
Content model: 
One or more <li> elements (Section 2.29) 
2.63.1. "anchor" Attribute 
Document-wide unique identifier for the list. 


2.63.2. "empty" Attribute 


Defines whether or not the label is empty. empty="true" indicates 
that no label will be shown. 


Allowed values: 
o "false" (default) 
o "true" 
2.63.3. "spacing" Attribute 
Defines whether or not there is a blank line between entries. 
spacing="normal" indicates a single blank line, while 
spacing="compact" indicates no space between. 
Allowed values: 


o "normal" (default) 


o "compact" 
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2.64. <uri> 
Contains a web address associated with the author. 


The contents should be a valid URI; this most likely will be an 
"http:" or "https:" URI. 


This element appears as a child element of <address> (Section 2.2). 
Content model: only text content. 
2.65. <workgroup> 


This element is used to specify the Working Group (IETF) or Research 
Group (IRTF) from which the document originates, if any. The 
recommended format is the official name of the Working Group (with 
some capitalization). 


In Internet-Drafts, this is used in the upper left corner of the 
boilerplate, replacing the "Network Working Group" string. 

Formatting software can append the words "Working Group" or "Research 
Group", depending on the "submissionType" property of the <rfc> 
element (Section 2.45.12). 


This element appears as a child element of <front> (Section 2.26). 
Content model: only text content. 
2.66. <xref> 


A reference to an anchor in this document. Formatters that have 
links (such as HTML and PDF) are likely to render <xref> elements as 
internal hyperlinks. This element is useful for referring to 
references in the "References" section, to specific sections of this 
document, to specific figures, and so on. The "target" attribute is 
required. 


This element appears as a child element of <annotation> 

(Section 2.3), <blockquote> (Section 2.10), <c> (Section 3.1), <cref> 
(Section 2.16), <dd> (Section 2.18), <dt> (Section 2.21), <em> 
(Section 2.22), <li> (Section 2.29), <name> (Section 2.32), 
<postamble> (Section 3.5), <preamble> (Section 3.6), <strong> 
(Section 2.50), <sub> (Section 2.51), <sup> (Section 2.52), <t> 
(Section 2.53), <td> (Section 2.56), <th> (Section 2.58), <tt> 
(Section 2.62), and <ttcol> (Section 3.9). 


Content model: only text content. 
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2.66.1. "format" Attribute 

This attribute signals to formatters what the desired format of the 

reference should be. Formatters for document types that have linking 

capability should wrap the displayed text in hyperlinks. 

"counter" 
The "derivedContent" attribute will contain just a counter. This 
is used for targets that are <section>, <figure>, <table>, or 
items in an ordered list. Using "format='counter' " where the 
target is any other type of element is an error. 
For example, with an input of: 


<section anchor="overview">Protocol Overview</section> 


See Section <xref target="overview" format="counter"/> 
for an overview. 


An HTML formatter might generate: 

See Section <a href="#overview">1.7</a> for an overview. 

"default" 

If the element has no content, the "derivedContent" attribute will 
contain a text fragment that describes the referenced part 
completely, such as "XML" for a target that is a <reference>, or 
"Section 2" or "Table 4" for a target to a non-reference. (If the 
element has content, the "derivedContent" attribute is filled with 
the content.) 
For example, with an input of: 

<section anchor="overview">Protocol Overview</section> 

See <xref target="overview"/> for an overview. 
An HTML formatter might generate: 

See <a href="#overview">Section 1.7</a> for an overview. 


"none" 


Deprecated. 
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"title" 


If the target is a <reference> element, the "derivedContent" 
attribute will contain the name of the reference, extracted from 
the <title> child of the <front> child of the reference. Or, if 
the target element has a <name> child element, the 
"derivedContent" attribute will contain the text content of that 
<name> element concatenated with the text content of each 
descendant node of <name> (that is, stripping out all of the XML 
markup, leaving only the text). Or, if the target element does 
not contain a <name> child element, the "derivedContent" attribute 
will contain the name of the "anchor" attribute of that element 
with no other adornment. 


Allowed values: 


o "default" (default) 
o "title" 
o "counter" 
o "none" 
2.66.2. "pageno" Attribute 
Deprecated. 


Allowed values: 


o "true" 
o "false" (default) 
2.66.3. "target" Attribute (Mandatory) 


Identifies the document component being referenced. The value needs 
to match the value of the "anchor" attribute of an element in the 
document; otherwise, it is an error. 
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This section lists the elements from v2 that have been deprecated. 
Note that some elements in v3 have attributes from v2 that are 
deprecated; those are not listed here. 


3.1. <c> 


Deprecated. Instead, 


use <tr>, <td>, and <th>. 


This element appears as a child element of <texttable> (Section 3.8). 


Content model: 
In any order: 


o Text 


o <bcp14> elements (Section 2.9) 


o <cref> elements (Section 2.16) 


o <em> elements (Section 2.22) 


o <eref> elements (Section 2.24) 


o <iref> elements (Section 2.27) 


o <spanx> elements (Section 3.7) 


o <strong> elements 


(Section 2.50) 


o <sub> elements (Section 2.51) 


o <sup> elements (Section 2.52) 


o <tt> elements (Section 2.62) 


o <xref> elements (Section 2.66) 


3.2. <facsimile> 


Deprecated. The <email> element is a much more useful way to get in 


touch with authors. 


This element appears as a child element of <address> 


Content model: only text content. 
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3.3. <format> 


Deprecated. If the goal is to provide a single URI for a reference, 
use the "target" attribute in <reference> instead. 


This element appears as a child element of <reference> 
(Section 2.40). 


Content model: this element does not have any contents. 


3.3.1. "octets" Attribute 
Deprecated. 

3.3.2. "target" Attribute 
Deprecated. 

3.3.3. "type" Attribute (Mandatory) 
Deprecated. 


3.4. <list> 
Deprecated. Instead, use <dl> for list/@style "hanging"; <ul> for 
list/@style "empty" or "symbols"; and <ol> for list/@style "letters", 
"numbers", "counter", or "format". 
This element appears as a child element of <t> (Section 2.53). 
Content model: 
One or more <t> elements (Section 2.53) 


SA: "counter" Attribute 


Deprecated. The functionality of this attribute has been replaced 
with <ol>/@start. 


3.4.2. "hangIndent" Attribute 
Deprecated. Use <dl> instead. 
3.4.3. "style" Attribute 


Deprecated. 
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3.5. <postamble> 
Deprecated. Instead, use a regular paragraph after the figure or 
table. 


This element appears as a child element of <figure> 


and <texttable> (Section 3.8). 


Content model: 


In any order: 


o Text 

o <bcp14> elements (Section 2.9) 

o <cref> elements (Section 2.16) 

o <em> elements (Section 2.22) 

o <eref> elements (Section 2.24) 

o <iref> elements (Section 2.27) 

o <spanx> elements (Section 3.7) 

o <strong> elements (Section 2.50) 

o <sub> elements (Section 2.51) 

o <sup> elements (Section 2.52) 

o <tt> elements (Section 2.62) 

o <xref> elements (Section 2.66) 
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3.6. <preamble> 


Deprecated. Instead, use a regular paragraph before the figure or 
table. 


This element appears as a child element of <figure> (Section 2.25) 
and <texttable> (Section 3.8). 


Content model: 
In any order: 
o Text 
o <bcp14> elements (Section 2.9) 
o <cref> elements (Section 2.16) 
o <em> elements (Section 2.22) 
o <eref> elements (Section 2.24) 
o <iref> elements (Section 2.27) 
o <spanx> elements (Section 3.7) 
o <strong> elements (Section 2.50) 
o <sub> elements (Section 2.51) 
o <sup> elements (Section 2.52) 
o <tt> elements (Section 2.62) 
o <xref> elements (Section 2.66) 
3.7. <spanx> 
Deprecated. 
This element appears as a child element of <annotation> 
(Section 2.3), <c> (Section 3.1), <postamble> (Section 3.5), 
<preamble> (Section 3.6), and <t> (Section 2.53). 


Content model: only text content. 
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3.7.1. "style" Attribute 
Deprecated. Instead of <spanx style="emph">, use <em>; instead of 
<spanx style="strong">, use <strong>; instead of <spanx 
style="verb">, use <tt>. 
3.7.2. "xml:space" Attribute 
Deprecated. 
Allowed values: 
o "default" 
o "preserve" (default) 
3.8. <texttable> 


Deprecated. Use <table> instead. 


This element appears as a child element of <aside> (Section 2.6) and 
<section> (Section 2.46). 


Content model: 

In this order: 

1. One optional <name> element (Section 2.32) 

2. One optional <preamble> element (Section 3.6) 


3. One or more <ttcol> elements (Section 3.9) 


4. Optional <c> elements (Section 3.1) 

5. One optional <postamble> element (Section 3.5) 
3.8.1. "align" Attribute 

Deprecated. 


Allowed values: 


o "left" 
o "center" (default) 
o "right" 
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3.8.2. "anchor" Attribute 
Deprecated. 

3.8.3. "style" Attribute 
Deprecated. 

3.8.4. "suppress-title" Attribute 
Deprecated. 


Allowed values: 
o "true" 
o "false" (default) 
3.8.5. "title" Attribute 
Deprecated. 
3.9. <ttcol> 
Deprecated. Instead, use <tr>, <td>, and <th>. 
This element appears as a child element of <texttable> (Section 3.8). 
Content model: 
In any order: 
o Text 
o <cref> elements (Section 2.16) 
o <eref> elements (Section 2.24) 
o <iref> elements (Section 2.27) 


o <xref> elements (Section 2.66) 
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3.9.1. "align" Attribute 
Deprecated. 
Allowed values: 


o "left" (default) 


o "center" 
o "right" 

3.9.2. "width" Attribute 
Deprecated. 


3.10. <vspace> 
Deprecated. In earlier versions of this format, <vspace> was often 
used to get an extra blank line in a list element; in the v3 
vocabulary, that can be done instead by using multiple <t> elements 
inside the <li> element. Other uses have no direct replacement. 


This element appears as a child element of <t> (Section 2.53). 


Content model: this element does not have any contents. 


3.10.1. "blanklLines" Attribute 
Deprecated. 
4. SVG 
The discussion of the use of SVG can be found in [RFC7996]. This 


element is part of the namespace "http://www.w3.org/2000/svg". 
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5. Use of CDATA Structures and Escaping 


A common problem authors have with <artwork> and <sourcecode> 
elements is that the XML processor returns errors if the text in the 
artwork contains either the "48" or "<" character, or the string 


"1]>". To avoid these problems, the "&" and "<" characters may be 
escaped using the strings "&amp;" and "£1t;", respectively; the "]]>" 
string can be represented as "]]&gt;". Alternatively, they may be 
surrounded in a CDATA structure: "<![CDATA[]]>". For example: 


Desired output: 
allowed-chars = "." mom Wen | won | ">." | ele 


Using escaping: 
<sourcecode> 

allowed=chars wom mom "gamp;" | "elt;" | "Egt;" | |e 
</sourcecode> 


Using CDATA: 

<sourcecode> 

<! [CDATA [ allowed-chars = "." | "on | Wen | won | ">." | vgs 
</sourcecode> 


Using CDATA is not a panacea, but it does help prevent having to use 
escapes in places where using escapes can cause other problems, such 
as difficulty of inclusion from other documents. 


6. Internationalization Considerations 


This format is based on [XML] and thus does not have any issues 
representing arbitrary Unicode [UNICODE] characters in text content. 
The RFC Series Editor may restrict some of the characters that can be 
used in a particular RFC; the rules for such restrictions are covered 
in [RFC7997]. 


7. Security Considerations 


The "name" attribute of the <artwork> element (Section 2.5.5) can be 
used to derive a filename for saving to a local file system. 
Trusting this kind of information without pre-processing is a known 
security risk; see Section 4.3 of [RFC6266] for more information. 


The "src" attribute of the <artwork> element can be used to read 
files from the local system. Processing tools must be careful to not 
accept dangerous values for the filename, particularly those that 
contain absolute references outside the current directory. 
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8. 


air 


The "type" attribute of the <artwork> and <sourcecode> elements is 
meant to encourage formatters to automatically extract known types of 
content from an RFC or Internet-Draft. While extraction is probably 
safe, those tools might also think that they could further process 
the extracted content, such as by rendering artwork or executing 
code. Doing so without first sanity-checking the extracted content 
is clearly a terrible idea from a security perspective. More 
generally, a tool that is reading XML input needs to be suspicious of 
any content that it intends to post-process. 


When there is an external reference to a URL, a processor or renderer 
should fetch the content into a sandbox and should have only a 


localized impact on the document processing and rendering. 


All security considerations related to XML processing are relevant as 
well (see Section 7 of [RFC3470]). 


IANA Considerations 
Internet Media Type Registration 


IANA maintains the registry of Internet Media Types [RFC6838] at 
<https://www.iana.org/assignments/media-types>. 


This document updates the specification for the Internet Media Type 
"application/rfc+xml" from the one in [RFC7749]. The following has 
been registered with IANA. 


Type name: application 

Subtype name: rfc+xml 

Required parameters: There are no required parameters. 
Optional parameters: "charset": This parameter has identical 


semantics to the charset parameter of the "application/xml" Media 
Type specified in Section 9.1 of [RFC7303]. 


Encoding considerations: Identical to those of "application/xml" as 
described in Section 9.1 of [RFC7303]. 


Security considerations: As defined in Section 7. In addition, as 
this Media Type uses the "+xml" convention, it inherits the 
security considerations described in Section 10 of [RFC7303]. 
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Interoperability considerations: Different implementations of this 
format have had interoperability issues. It is not expected that 
publication of this application will cause those implementations 
to be fixed. 


Published specification: This specification. 

Applications that use this Media Type: Applications that transform 
xml2rfc to output representations such as plain text or HTML, plus 
additional analysis tools. 

Fragment identifier considerations: The "anchor" attribute is used 
for assigning document-wide unique identifiers that can be used as 
shorthand pointers, as described in [XPOINTER]. 

Additional information: 

Deprecated alias names for this type: None 


Magic number(s): As specified for "application/xml" in [RFC7303]. 


File extension(s): .xml or .rfcxml when disambiguation from other 
XML files is needed 


Macintosh file type code(s): TEXT 


Person & email address to contact for further information: See the 
Author’s Address section of RFC 7991. 


Intended usage: COMMON 

Restrictions on usage: None 

Author: See the Author's Address section of RFC 7991. 

Change controller: RFC Series Editor (rse@rfc-editor.org) 
8.2. Link Relation Registration 


IANA has registered "convertedFrom" in the "Link Relation Types" 
registry [LINKRELATIONS]. 


Relation Name: convertedFrom 
Description: The document linked to was later converted to the 
document that contains this link relation. For example, an RFC can 


have a link to the Internet-Draft that became the RFC; in that case, 
the link relation would be "convertedFrom". 
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This document. 


Notes: This relation is different than "predecessor-version" in that 
"predecessor-version" is for items in a version control system. It 
is also different than "previous" in that this relation is used for 
converted resources, not those that are part of a sequence of 


resources. 


Application Data: None 
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Appendix A. Front-Page ("Boilerplate") Generation 


The values listed here will be defined by the RFC Series Editor. 
Those listed here are believed to be the current values in use. 


A.l. The "ipr" Attribute 


This attribute value can take a long list of values, each of which 
describes an IPR policy for the document (Section 2.45.5). The 
values are not the result of a grand design, but they remain simply 
for historic reasons. Of these values, only a few are currently in 
use; all others are supported by various tools for backwards 
compatibility with old source files. 


Note: Some variations of the boilerplate are selected based on the 
document’s date; therefore, it is important to specify the "year", 
"month", and "day" attributes of the <date> element when archiving 
the XML source of an Internet-Draft on the day of submission. 


_Disclaimer: THIS ONLY PROVIDES IMPLEMENTATION INFORMATION. IF YOU 
NEED LEGAL ADVICE, PLEASE CONTACT A LAWYER._ For further 
information, refer to <http://trustee.ietf.org/docs/ 
IETF-Copyright-FAQ.pdf>. 


For the current "Copyright Notice" text, the submissionType attribute 
of the <rfc> element (Section 2.45.12) determines whether a statement 
about "Code Components" is inserted (which is the case for the value 

"IETF", which is the default). Other values, such as "independent", 

suppress this part of the text. 


A.1.1. Current Values: "*trust200902" 


The name for these values refers to version 2.0 of the IETF Trust’s 
"Legal Provisions Relating to IETF Documents", sometimes simply 
called the "TLP", which went into effect on February 15, 2009 
[TLP2.0]. Updates to the document were published on September 12, 
2009 [TLP3.0] and on December 28, 2009 [TLP4.0], modifying the 
license for code components (see <http://trustee.ietf.org/ 


license-info/> for further information). The actual text is located 
in Section 6 ("Text to Be Included in IETF Documents") of these 
documents. 
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The prep tool automatically produces the "correct" text, depending on 
the document’s date information (see above): 


+---------- + 
| TLP | starting with publication date | 
are +-------------------------------- + 
| [TLP3.0] | 2009-11-01 | 
| [TLP4.0] | 2010-04-01 | 
+---------- a a a + 


The TLP was again updated in March 2015 [TLP5.0], but the changes 
made in that version do not affect the boilerplate text. 


A.1.1.1. trust200902 
This value should be used unless one of the more specific 
"*trust200902" values is a better fit. It produces the text in 
Sections 6.a and 6.b of the TLP. 

A.1.1.2. noModificationTrust200902 


This produces the additional text from Section 6.c.i of the TLP: 


This document may not be modified, and derivative works of it may 
not be created, except to format it for publication as an RFC or 
to translate it into languages other than English. 


Note: this clause is incompatible with RFCs that are published on 
the Standards Track. 


A.1.1.3. noDerivativesTrust200902 
This produces the additional text from Section 6.c.ii of the TLP: 


This document may not be modified, and derivative works of it may 
not be created, and it may not be published except as an 
Internet-Draft. 


Note: this clause is incompatible with RFCs. 
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A.1.1.4. pre5378Trust200902 


This produces the additional text from Section 6.c.iii of the TLP, 
frequently called the "pre-5378 escape clause" referring to changes 
introduced in [RFC5378]: 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) 
controlling the copyright in such materials, this document may not 
be modified outside the IETF Standards Process, and derivative 
works of it may not be created outside the IETF Standards Process, 
except to format it for publication as an RFC or to translate it 
into languages other than English. 


See Section 4 of <http://trustee.ietf.org/docs/ 
IETF-Copyright-FAQ.pdf> for further information about when to use 
this value. 


Note: this text appears under "Copyright Notice", unless the 
document was published before November 2009, in which case it 
appears under "Status of This Memo". 


A.1.2. Historic Values 
A.1.2.1. Historic Values: "*trust200811" 
The attribute values "trust200811", "noModificationTrust200811", and 
"noDerivativesTrust200811" are similar to their "trust200902" 
counterparts, except that they use text specified in [TLP1.0]. 
A.1.2.2. Historic Values: "*3978" 
The attribute values "ful13978", "noModification3978", and 


"noDerivatives3978" are similar to their counterparts above, except 
that they use text specified in [RFC3978]. 


A.1.2.3. Historic Values: "*3667" 
The attribute values "full3667", "noModification3667", and 


"noDerivatives3667" are similar to their counterparts above, except 
that they use text specified in [RFC3667]. 
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A.1.2.4. Historic Values: "*2026" 


The attribute values "full2026" and "noDerivativeWorks2026" are 
similar to their counterparts above, except that they use text 
specified in Section 10 of [RFC2026]. 


The special value "none" was also used back then; it denied the IETF 
any rights beyond publication as an Internet-Draft. 


A.2. The "submissionType" Attribute 


The RFC Editor publishes documents from different "document streams", 
of which the "IETF stream" is the most prominent. Other streams are 
the "Independent Submissions stream" (used for things such as 
discussion of Internet-related technologies that are not part of the 
IETF agenda), the "IAB stream" (Internet Architecture Board), and the 
"IRTF stream" (Internet Research Task Force). 


The values for the attribute are "IETF" (the default value), 
"independent", "IAB", and "IRTE". 


Historically, this attribute did not affect the final appearance of 
RFCs, except for subtle differences in copyright notices. Nowadays 
(as of [RFC7841]), the stream name appears in the first line of the 
front page, and it also affects the text in the "Status of This Memo" 
section. 


For current documents, setting the "submissionType" attribute will 
have the following effect: 


o For RFCs, the stream name appears in the upper left corner of the 
first page (in Internet-Drafts, this is either "Network Working 
Group" or the value of the <workgroup> element). 


o For RFCs, it affects the whole "Status of This Memo" section (see 
Section 3.2 of [RFC7841]). 


o For all RFCs and Internet-Drafts, it determines whether the 
"Copyright Notice" section mentions the Copyright on Code 
Components (see Section 6 of the TLP ("Text to Be Included in IETF 
Documents")). 
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A.3. The "consensus" Attribute 


For some of the publication streams (see Appendix A.2), the "Status 
of This Memo" section depends on whether there was a consensus to 
publish (again, see Section 3.4 of [RFC7841]). 


The consensus attribute can be used to supply this information. The 
acceptable values are "true" (the default) and "false"; "yes" and 
"no" from v2 are deprecated. 


The effect of this value for the various streams is: 


o "independent": none. 

o "IAB": mention that there was an IAB consensus. 

o "IETF": mention that there was an IETF consensus. 

o "IRTF": mention that there was a research group consensus (where 
the name of the research group is extracted from the <workgroup> 
element). 
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Appendix B. The v3 Format and Processing Tools 


This section describes topics that are specific to v3 processing 
tools. Note that there is some discussion of tools in the main body 


of the document as well. For example, some elements have 
descriptions of how a processing tool might create output from the 
element. 


The expected design of the tools that will be used with v3 documents 
includes: 


o 


A "prep tool" that takes a v3 document, makes many checks, adds 
and changes many attribute values, and creates a file that is a 
"prepared document". The prepared document is a valid v3 
document. The prep tool is described in [RFC7998]. 


The prep tool is expected to have many modes: 


* RFC mode -- The mode used by the RFC Editor to process the 
input from one of the RFC streams and to process XML produced 
during the RFC editing process. The restrictions on the 
canonical XML for RFCs, as well as how the non-canonical 
formats will look, are described at 
<https://www.rfc-editor.org/rse/wiki/ 
doku.php?id=design: format-and-content-rfcs>. 


* Draft mode -- The mode used by the Internet-Draft submission 
tool. The restrictions for the XML from this mode will be 
described later. 


* Diagnostic mode -- A mode that can be used by document authors 
to look for errors or warnings before they submit their 
documents for publication. 


* Consolidation mode -- Produces output where no external 
resources are required to render the file output. This 
includes expanding the XInclude entities and DTD entities in 
place, and changing all elements that have "src" attributes 
with external links into either "data:" URI or content for the 
element, as specified in [RFC7998]. 


Formatting tools that will create HTML, PDF, plain text, and 
possibly other output formats. These formatters will be created 
by the IETF, but others can create such tools as well. The IETF 
tools are expected to take prepared documents as input. 
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There may also be processing tools that are meant to run on the 
computers of authors. These tools may be used to produce interim 
versions of the non-canonical representations so that authors can see 
how their XML might later be rendered, to create documents in 
representations different than those supported by the RFC Editor, to 
possibly create documents that are not meant to be Internet-Drafts or 
RFCs, and to convert XML that has external information into XML that 
has that external information included. 


The prep tool is expected to have clear error reporting, giving more 
context than just a line number. For example, the error messages 
should differentiate between errors in XML and those from the v3 


format. 

In v2, the grammar was specified as a DID. In v3, the grammar is 
specified only as RELAX Next Generation (RNG). This means that tools 
need to work from the RNG, not from a DTD. Some of the features of 


the v3 grammar cannot be specified as a DTD. 
B.1. Including External Text with XInclude 


All tools for the v3 format are expected to support XInclude 
[XInclude]. XInclude specifies a processing model and syntax for 
general-purpose inclusion of information that is either on the 
Internet or local to the user’s computer. 


In the v3 syntax, XInclude is expressed as the <xi:include> element. 
To use this element, you need to include the "xi" namespace in the 
<rfc> element; that is, you need to specify 


xmlns:xi="http://www.w3.org/2001/XInclude" 
as one of the attributes in the <rfc> element. 


The most common way to use <xi:include> is to pull in references that 
are already formed as XML. Currently, this can be done from 
xml2rfc.tools.ietf.org, but later this is expected to be from the RFC 
Editor. For example, if a document has three normative references, 
all RFCs, the document might contain: 


<references> 
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/ 
bibxml/reference.RFC.2119.xm1"/> 
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/ 
bibxml/reference.RFC.4869.xml"/> 
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/ 
bibxml/reference.RFC.7169.xm1"/> 
</references> 
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B. 


B. 


<xi:include> can be used anywhere an XML element could be used (but 
not where free text is used). For example, if three Internet-Drafts 
are all including a particular paragraph or section verbatim, that 
text can be kept either in a file or somewhere on the web and can be 
included with <xi:include>. An example of pulling something from the 
local disk would be: 


<x:include href="file://home/chris/ietf/drafts/commontext.xml"/> 


In general, XInclude should be used instead of ENTITY references and 
XML Processing Instructions (PIs) that allow external inclusions. 


2. Anchors and IDs 


People writing and reading Internet-Drafts and RFCs often want to 
make reference to specific locations in those documents. In the case 
of RFC authors, it is common to want to reference another part of 
their document, such as "see Section 3.2 of this document." Readers, 
on the other hand, want to reference parts of documents that they 
didn’t write, such as "see Section 3.2 of RFC 6949." The XML 
vocabulary in this document attempts to support both sets of people. 


Authors can leave anchors in a document that can later be used for 
references with the "anchor" attribute. Anchors can be included in 
the numerous elements. The author can then refer to that anchor in 
the "target" attribute of the <xref> element. 


Readers can refer to any element that has an "anchor" attribute by 
that attribute. Note, however, that most of the time, elements won’t 
have anchors. In the common case, the reader wants to refer to an 
element that does not have an "anchor" attribute, but that element 
has a "pn" attribute. 


Processing tools add the "pn" attribute to many elements during 
processing. This attribute and its value are automatically generated 
by the tool if the attribute is not there; if the attribute is 
already there, the tool may replace the value. 


2.1. Overlapping Values 


In the HTML representation of this XML vocabulary, both anchors and 
"pn" attributes will be used in the "id" attributes of elements. 
Thus, there can be no overlap between the names entered in "anchor" 
attributes, in "slugifiedName" attributes, and those that are 
generated for the "pn" attributes. Also, there are some values for 
the "anchor" values that are reserved for sections, and those 
sections can only have those anchor values. 
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The following rules prevent this overlap: 


o 


"pn" for regular sections always has the format "s-nnn", where 
"nnn" is the section number, or the appendix identifier (which 
starts with a letter). For example, this would be "s-2.1.3" for 
Section 2.1.3 and "s-a" for Appendix A. For the <abstract> 
element, it is always "s-abstract". For the <note> element, it is 
always "s-note-nnn", where "nnn" is a sequential value. For 
sections in the <boilerplate> element, it is always 
"s-boilerplate-nnn", where "nnn" is a sequential value. 


"on" for <references> elements has the format "s-nnn". It is 
important to note that "nnn" is a number, not letters, even though 
the <references> appear in the back. It is the number that is one 
higher than the highest top-level section number in <middle>. If 
there are two or more <references>, "nnn" will include a dot as if 
the <references> are a subsection of a section that is numbered 
one higher than the highest top-level section number in <middle>. 


"on" for <figure> elements always has the format "f-nnn", where 
"nnn" is the figure number. For example, this would be "f-5" for 
Figure 5. 


"on" for <iref> elements always has the format "i-ttt-nnn", where 
"ttt" is the slugified item (plus a hyphen and the slugified 
subitem if there is a subitem), and "nnn" is the instance of that 
item/subitem pair. For example, this would be "i-foo-1" for 
"<iref item=’foo’>" and "i-foo-bar-1" for "<iref item=’ foo’ 
subitem='’bar’>". 


"on" for <table> elements always has the format "t-nnn", where 
"nnn" is the table number. For example, this would be "t-5" for 
Table 5. 


"on" for all elements not listed above always has the format 
"p-nnn-mmm", where "nnn" is the section number and "mmm" is the 
relative position in the section. For example, this would be 
"p-2.1.3-7" for the seventh part number in Section 2.1.3. 
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o "slugifiedName" always has the format "n-ttt", where "ttt" is the 
text of the name after slugification. For example, this would be 
"n-protocol-overview" for the name "Protocol Overview". The 


actual conversions done in slugification will be specified at a 
later time. 


o Anchors must never overlap with any of the above. The easiest way 
to assure that is to not pick an anchor name that starts with a 
single letter followed by a hyphen. If an anchor does overlap 
with one of the types of names above, the processing tool will 
reject the document. 


B.3. Attributes Controlled by the Prep Tool 


Many elements in the v3 vocabulary have new attributes whose role is 
to hold values generated by the prep tool. These attributes can 
exist in documents that are input to the prep tool; however, any of 
these attributes might be added, removed, or changed by the prep 
tool. Thus, it is explicitly unsafe for a document author to include 
these attributes and expect that their values will survive processing 
by the prep tool. 


The attributes that are controlled by the prep tool are: 


o The "pn" attribute in any element -- The number for this item 
within the section. The numbering is shared with other elements 
of a section. The "pn" attribute is added to many block-level 
elements inside sections. 


o <artwork> originalSrc -- This attribute is filled with the 
original value of the "src" attribute if that attribute is removed 
by the prep tool. 


o <figure> originalSrc -- This attribute is filled with the original 
value of the "src" attribute if that attribute is removed by the 
prep tool. 

o <name> "slugifiedName" attribute -- This attribute is filled with 
a "slugified" version of the text in the element. This attribute 


can be used in the output formats for elements that have both 
names and numbers. 


o <relref> "derivedLink" attribute -- This attribute is filled with 
the link that is derived from combining the URI from the reference 
and the relative part that is either a copy of the "relative" 
attribute or a section number derived from the "section" 
attribute. 


Hoffman Informational [Page 102] 


RFC 7991 The "xml2rfc" Version 3 Vocabulary December 2016 


o <rfc> "expiresDate" attribute -- This attribute is filled with the 
date that an Internet-Draft expires. The date is in the format 
yyyy-mm-dd. 

o <rfc> "mode" attribute -- This attribute is filled with a string 


that indicates what mode the prep tool was in when it processed 
the XML, such as whether it was processing a file to become an 
Internet-Draft or an RFC. 


o <rfc> "scripts" attribute -- This attribute is filled with a list 
of scripts needed to render this document. The list is comma- 
separated, with no spaces allowed. The order is unimportant. The 
names come from [UAX24]. For example, if the document has Chinese 
characters in it, the value might be "Common, Latin, Han". 


o <sourcecode> "originalSrc" attribute -- This attribute is filled 
with the original value of the "src" attribute if that attribute 
is removed by the prep tool. 


o <xref> "derivedContent" attribute -- This attribute is filled in 
if there is no content in the <xref> element. The value for this 
attribute is based on the value in the "displayFormat" attribute. 
Examples of how this value is filled can be found in 
Section 2.66.1. 


In addition, note that the contents of the <boilerplate> element are 
controlled by the prep tool. 
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Appendix C. RELAX NG Schema 
The following is the RELAX NG schema for the v3 format. 
namespace a = "http: //relaxng.org/ns/compatibility/annotations/1.0" 
# xml2rfc Version 3 grammar 


CEG S 
element rfc { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute number { text }?, 
[ a:defaultValue = "" ] attribute obsoletes { text }?, 
[ a:defaultValue = "" ] attribute updates { text }?, 
attribute category { text }?, 
attribute mode { text }?, 
[ a:defaultValue = "false" ] 
attribute consensus { "no" | "yes" | "false" "true" 17, 
attribute seriesNo { text }?, 
attribute ipr { text }?, 
attribute iprExtract { xsd: IDREF }?, 


[ a:defaultValue = "IETF" ] 
attribute submissionType { 
"IETF" | "IAB" | "IRTF" | "independent" 


}?, 
attribute docName { text }?, 


[ a:defaultValue = "false" ] 

attribute sortRefs { "true" | "false" }?, 

[ a:defaultValue = "true" ] 

attribute symRefs { "true" | "false" }?, 

[ a:defaultValue = "true" ] 

attribute tocInclude { "true" | "false" }?, 

[ a:defaultValue = "3" ] attribute tocDepth { text }?, 
attribute prepTime { text }?, 

[ a:defaultValue = "true" ] 

attribute indexInclude { "true" | "false" }?, 
attribute version { text }?, 

[ a:defaultValue = "Common, Latin" ] attribute scripts { text }?, 
attribute expiresDate { text }?, 

link*, 

front, 

middle, 

back? 
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link = 
element link ( 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute href { text }, 
attribute rel { text }? 
} 


front = 

element front { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
title, 
seriesInfo*, 
author+, 
date?, 
area*, 
workgroup*, 
keyword*, 
abstract?, 
note*, 
boilerplate? 


} 


title = 

element title { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute abbrev { text }?, 
attribute ascii { text }?, 
text 

} 


author = 
element author { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute initials { text }?, 


attribute asciilnitials { text }?, 
attribute surname { text }?, 
attribute asciiSurname { text }?, 


attribute 


fullname { text }?, 


attribute role { "editor" }?, 
attribute asciiFullname { text }?, 
organization?, 
address? 
} 
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orga 
el 


} 


addr 
el 


} 


post 
el 


stre 
el 


} 


city 
el 
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nization = 
ement organization { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute abbrev { text }?, 
attribute ascii { text }?, 
text 


ess = 
ement address { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 
postal?, 

phone?, 

facsimile?, 

email?, 

uri? 


al = 

ement postal { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 


December 2016 


((city | code | country | region | street)* | postalLine+) 


et = 

ement street { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 


ement city { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
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region = 
element region ( 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
} 


code = 
element code { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 


country = 
element country { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
} 


postalLine = 
element postalLine { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
} 


phone = 
element phone { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 


facsimile = 
element facsimile { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
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email = 
element email ( 
attribute xml:base { text }?, 


attribute xml:lang ([ text }?, 
attribute ascii { text }?, 
text 


} 


uri = 
element uri { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 
date = 
element date { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute day { text }?, 
attribute month { text }?, 
attribute year { text }?, 
empty 
} 
area = 
element area { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 
workgroup = 
element workgroup { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 
keyword = 
element keyword { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 
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abstract = 
element abstract ( 
attribute xml:base { text 
attribute xml:lang { text 
attribute anchor { xsd:ID 
attribute pn { text }?, 
(dl | ol | t | ul)+ 


note = 
element note { 
attribute xml:base { text 
attribute xml:lang { text 
attribute title { text }?, 
attribute pn { text }?, 
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}?, 
}?, 
}?, 


[ a:defaultValue = "false" ] 
attribute removeInRFC { "true" | "false" }?, 
name?, 


(dal | ol | t | ul)+ 
} 


boilerplate = 
element boilerplate { 
attribute xml:base { text 
attribute xml:lang { text 
section+ 


} 


middle = 
element middle { 
attribute xml:base { text 
attribute xml:lang { text 
section+ 


Hoffman 


12, 


}?, 


Informational 


December 2016 


[Page 109] 


RFC 7991 


section = 


The "xml2rfc" Version 3 Vocabulary 


element section { 


attribute 
attribute 
attribute 
attribute 
attribute 


xml:base { text }?, 
xml:lang { text }?, 
anchor { xsd:ID }?, 
pn { text }?, 

title { text }?, 


[ a:defaultValue = "true" 


] 


attribute numbered { "true" | "false" }?, 
[ a:defaultValue = "default" ] 
attribute toc { "include" | "exclude" | "default" }?, 


[ a:defaultValue = "false" 


] 


attribute removeInRFC { "true" | "false" }?, 


name?, 
(artwork 
aside 
blockquote 
| al 

| figure 

| iref 

| ol 

| sourcecode 
| 

| 

| 

e 


t 

table 
texttable 
ul)*, 


section* 


name = 
element name { 
attribute xml:base { text 
attribute xml:lang { text 


}?, 
}?, 


attribute slugifiedName { text }?, 
(text | cref | eref | relref | tt | xref)* 
} 
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t = 
element t { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 
attribute hangText { text }?, 
[ a:defaultValue = "false" ] 
attribute keepWithNext { "false" | "true" }?, 
[ a:defaultValue = "false" ] 
attribute keepWithPrevious { "false" | "true" }?, 
(text 
| bep14 
| cref 
| em 
eref 
| iref 
| \list 
| relref 
| spanx 
| strong 
| sub 
sup 
| tt 
| vspace 
| xref)* 


} 


aside = 
element aside { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 
(artwork | dl | figure | iref | Mist | 01 | t | table | ul)* 
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element blockquote { 


attribute 
attribute 
attribute 
attribute 
attribute 
attribute 


xml:base { text 
xml:lang { text 
anchor { xsd: ID 
pn { text }?, 

cite { text }?, 
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}?, 
12, 
}?, 


quotedFrom { text }?, 


( (artwork 

| (text 
bcp14 

| cref 

| em 

| eref 

| iref 

relref 

strong 

sub 

sup 

EE 

xref) +) 


} 


Vlist = 
element list { 
attribute xml:base 
attribute xml:lang 
[ a:defaultValue = 


| dl | figure | ol | sourcecode | t | ul)+ 


{ text }?, 
{ text }?, 


"empty" ] attribute style { text 


attribute hangIndent { text }?, 
attribute counter { text }?, 
attribute pn { text }?, 


t+ 


ol = 
element ol { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
[ a:defaultValue = 
[ a:defaultValue = 


{ text }?, 
{ text }?, 
xsd:ID }?, 
"1" ] attribute type { text }?, 
"1" ] attribute start { text }?, 


attribute group { text }?, 


[ a:defaultValue = "normal" ] 
attribute spacing { "normal" | "compact" }?, 
attribute pn { text }?, 
1i+ 
) 
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ul = 
element ul { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 


[ a:defaultValue = "normal" ] 

attribute spacing { "normal" | "compact" }?, 
([ a:defaultValue = "false" ] 

attribute empty { "false" | "true" }, 


attribute pn { text }?)?, 
li+ 


li = 
element li { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 


( (artwork | dl | figure | ol | sourcecode | t | ul)+ 


| (text 
bcp14 
| cref 
| em 
| eref 
| iref 
| relref 
| strong 
sub 
| sup 
| | tt 
| xref) +) 


dl = 
element dl { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 


[ a:defaultValue = "normal" ] 

attribute spacing { "normal" | "compact" }?, 
[ a:defaultValue = "true" ] 

attribute hanging { "false" | "true" }?, 


attribute pn { text }?, 
(dt, dd)+ 
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dt = 


element dt { 


attribute 
attribute 
attribute 
attribute 
(text 
| bep14 
| cref 
em 
| eref 
| iref 
| relref 
| strong 
| sub 
| sup 
tE 
| xref)* 


dd = 


element dd { 


attribute 
attribute 
attribute 
attribute 
( (artwork 
| (text 
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xml:base { text 
xml:lang { text 
anchor { xsd:ID 
pn { text }?, 


xml:base { text 
xml:lang { text 
anchor { xsd:ID 
pn { text }?, 


| dl | figure | ol | sourcecode | t | ul)+ 


bcp14 
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}?, 
}?, 
}?, 


Hoffman 


cref 
em 
eref 
iref 
relref 
strong 
sub 
sup 

EE 
xref)+) 
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xref 


element xref { 


[ a:defaultValue = "false" ] 
attribute pageno { "true" | "false" }?, 
[ a:defaultValue = "default" ] 
attribute format { "default" | "title" | "counter" 
attribute derivedContent { text }?, 
text 
} 
relref = 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { xsd:IDREF }, 


element relref { 


} 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { xsd:IDREF }, 
[ a:defaultValue = "of" ] 


December 2016 


"none" }?, 


attribute displayFormat { "of" | "comma" | "parens" | "bare" }?, 


attribute section { text }, 
attribute relative { text }?, 
attribute derivedLink { text }?, 
text 


eref = 
element eref { 


} 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { text }, 
text 


iref = 
element iref { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute item { text }, 


[ a:defaultValue = "" ] attribute subitem { text }?, 
[ a:defaultValue = "false" ] 

attribute primary { "true" | "false" }?, 

attribute pn { text }?, 

empty 
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cref = 
element cref { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute source { text }?, 
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[ a:defaultValue = "true" ] 
attribute display { "true" | "false" )?, 
(text | em | eref | relref | strong | sub | sup | tt | xref)* 


tt = 
element tt ( 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text 
| bep14 
| cref 
| em 
| eref 
| iref 
relref 
strong 
sub 


n 
E 
ue) 


xref) * 


strong = 
element strong { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text 
bcp14 
| cref 
| em 
| eref 
| iref 
| relref 
| sub 
sup 
[ER 
| xref) * 
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em..= 


element em ( 


attribute 
attribute 
(text 

| bcp14 

| cref 

| eref 
iref 
relref 
strong 
sub 
sup 
tt 
xref)* 


} 


sub = 
element sub 
attribute 
attribute 
(text 
| bep14 
| cref 
| em 
| eref 
| iref 
relref 
strong 
tt 
xref)* 


sup = 
element sup 
attribute 
attribute 
(text 
| bcp14 
cref 
be 
| eref 
| iref 
| relref 
| strong 
tt 
| xref)* 
) 
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xml:base { text }?, 
xml:lang { text }?, 


{ 
xml:base { text }?, 
xml:lang { text }?, 


{ 
xml:base { text }?, 
xml:lang { text }?, 
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spanx = 
element spanx { 

attribute xml:base { text }?, 

attribute xml:lang { text }?, 


[ a:defaultValue = "preserve" ] 

attribute xml:space { "default" | "preserve" }?, 

[ a:defaultValue = "emph" ] attribute style { text }?, 
text 


vspace = 
element vspace { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
[ a:defaultValue = "0" ] attribute blankLines { text }?, 
empty 
} 


figure = 
element figure { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 


[ a:defaultValue = "" ] attribute title { text }?, 
[ a:defaultValue = "false" ] 
attribute suppress-title { "true" | "false" )?, 


attribute src { text }?, 

attribute originalSrc { text }?, 

[ a:defaultValue = "left" ] 

attribute align { "left" | "center" | "right" }?, 
[ a:defaultValue "" ] attribute alt { text }?, 

[ a:defaultValue = "" ] attribute width { text }?, 
[ a:defaultValue = "" ] attribute height { text }?, 
name?, 

iref*, 

preamble?, 

(artwork | sourcecode) +, 

postamble? 
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table = 
element table { 


} 


attribute 
attribute 
attribute 
attribute 
name?, 
iref*, 
thead?, 
tbody+, 
tfoot? 


preamble = 
element preamble ( 


Hoffman 


attribute 
attribute 
(text 
| bcp14 
| cref 
| em 
| eref 
iref 
| relref 
| spanx 
| strong 
| sub 
| sup 
tt 
| xref)* 
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xml:base { text }?, 
xml:lang { text }?, 
anchor { xsd:ID }?, 
pn { text }?, 


xml:base { text }?, 
xml:lang { text }?, 
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artwork = 
element artwork { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 
attribute xml:space { text }?, 


[ a:defaultValue = "" ] attribute name { text }?, 

[ a:defaultValue = "" ] attribute type { text }?, 
attribute sre { text }?, 

[ a:defaultValue = "left" ] 

attribute align { "left" | "center" | "right" }?, 

[ a:defaultValue = "" ] attribute alt { text }?, 

[ a:defaultValue = "" ] attribute width { text }?, 
[ a:defaultValue = "" ] attribute height { text }?, 
attribute originalSrc { text }?, 


(text* | svg) 
} 
# https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc 


sourcecode = 

element sourcecode { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 
[ a:defaultValue = "" ] attribute name { text }?, 
[ a:defaultValue = "" ] attribute type { text }?, 
attribute sre { text }?, 
attribute originalSrc { text }?, 
text 

} 


thead = 
element thead { 
attribute xml:base { text }? 
attribute xml:lang { text }? 
attribute anchor { xsd:ID }? 
tr+ 
) 


tbody = 
element tbody ( 
attribute xml:base { text }? 
attribute xml:lang { text }? 
attribute anchor { xsd:ID }? 
tr+ 
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tfoot = 
element tfoot { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
trt+ 


tr = 
element tr { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
(td | th)+ 


td = 
element td { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
[ a:defaultValue = 
[ a:defaultValue = 
[ a:defaultValue = 


"xml2rfc" 
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{ text }?, 
{ text }?, 
xsd:ID }?, 


{ text }?, 
{ text }?, 
xsd:ID }?, 


{) EXE } 2, 
{ text }?, 
xsd:ID }?, 
rom ] 
TON ] 
"ett" 1] 


attribute align { "left" | "center" | "right" }?, 


((artwork | dl | figure | ol | sourcecode | t | ul)+ 


| (text 
bcp14 
br 
cref 
em 
eref 
iref 
relref 
strong 
sub 
sup 

EE 
xref)*) 
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attribute colspan { text }?, 
attribute rowspan { text }?, 
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th = 
element th ( 
attribute xml:base { text }?, 
attribute xml:lang ([ text }?, 
attribute anchor { xsd:ID }?, 
[ a:defaultValue = "0" ] attribute colspan { text }?, 
[ a:defaultValue = "0" ] attribute rowspan { text }?, 
[ a:defaultValue = "left" ] 
attribute align { "left" | "center" | "right" }?, 
( (artwork | dl | figure | ol | sourcecode | t | ul)+ 
| (text 
| bep14 
| br 
| cref 
| em 
| eref 
iref 
| relref 
| strong 
| sub 
| sup 
tt 
| xref)*) 


} 


postamble = 
element postamble { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text | cref | eref | iref | spanx | xref)* 
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texttable = 
element texttable { 
attribute xml:base { text }?, 
attribute xml:lang ([ text }?, 
attribute anchor { xsd:ID }?, 


[ a:defaultValue = "" ] attribute title { text }?, 
[ a:defaultValue = "false" ] 

attribute suppress-title { "true" | "false" )?, 

[ a:defaultValue = "center" ] 

attribute align { "left" | "center" | "right" }?, 
[ a:defaultValue = "full" ] 

attribute style { "all" | "none" | "headers" | TEULE 2, 
name?, 

preamble?, 

ttcol+, 

EX; 

postamble? 


} 


ttcol = 
element ttcol { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute width { text }?, 


[ a:defaultValue = "left" ] 
attribute align { "left" | "center" | "right" }?, 
(cref | eref | iref | xref | text)* 


c= 
element c { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text | cref | eref | iref | spanx | xref)* 


} 


bcp14 = 
element bcp14 { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
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br = 
element br { 
attribute xml:base { text }?, 
attribute xml:lang ([ text }?, 
empty 
} 


back = 
element back { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
displayreference*, 
references*, 
section* 


} 


displayreference = 
element displayreference { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { xsd:IDREF }, 
attribute to { text } 
} 


references = 
element references { 

attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute pn { text }?, 
attribute anchor { xsd:ID }?, 
attribute title { text }?, 
name?, 
(reference | referencegroup)* 


} 


reference = 
element reference { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }, 
attribute target { text }?, 


[ a:defaultValue = "true" ] 
attribute quoteTitle { "true" | "false" }?, 
front, 
(annotation | format | refcontent | seriesInfo) * 
} 
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element referencegroup { 


} 


attribute 
attribute 
attribute 


reference+ 


seriesInfo = 
element seriesInfo ( 


attribute 
attribute 
attribute 
attribute 
attribute 


xml:base { text }?, 
xml:lang { text }?, 
anchor { xsd:ID }, 


xml:base { text }?, 
xml:lang { text }?, 
name { text }, 
value { text }, 
asciiName { text }?, 


attribute asciiValue { text }?, 
attribute status { text }?, 
[ a:defaultValue = "IETF" ] 
attribute stream { "IETF" | "IAB" 
empty 

} 

format = 

element format { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { text }?, 
attribute type { text }, 
attribute octets { text }?, 
empty 

} 
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annotation = 
element annotation ( 
attribute xml:base { text }?, 
attribute xml:lang ([ text }?, 
(text 
| bep14 
| cref 
| em 
eref 
| irer 
| relref 
| spanx 
| strong 
| sub 
| sup 
tt 
| xref)* 


} 


refcontent = 
element refcontent { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text | bcp14 | em | strong | sub | sup | GENS 
} 


start |= ric 


Hoffman Informational [Page 126] 


RFC 7991 The "xml2rfc" Version 3 Vocabulary December 2016 


Appendix D. Schema Differences from v2 
The following is a non-normative comparison of the v3 format to the 
v2 format. A "-" indicates lines removed from the v2 schema, and a 


"+" indicates lines added to the v3 schema. 


namespace a = 
"http://relaxng.org/ns/compatibility/annotations/1.0" 


+ # xml2rfc Version 3 grammar 


rie = 
element rfc { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute number { text }?, 
[ a:defaultValue = "" ] attribute obsoletes { text }?, 
[ a:defaultValue = "" ] attribute updates { text }?, 
= attribute category { "std" | "bcp" | "info" | "exp" | 
= "historic" }?, 
= attribute consensus { "no" | "yes" }?, 


+ attribute category { text }?, 

+ attribute mode { text }?, 

+ [ a:defaultValue = "false" ] 

+ attribute consensus { "no" | "yes" | "false" "erue y 


attribute seriesNo { text }?, 
= attribute ipr { 
= "full2026" 
"noDerivativeWorks2026" 
| "none" 
| "ful113667" 
| "noModification3667" 
| "noDerivatives3667" 
| "£fu113978" 
- | "noModification3978" 
"noDerivatives3978" 
| "trust200811" 
| "noModificationTrust200811" 
| "noDerivativesTrust200811" 
| "trust200902" 
| "noModificationTrust200902" 
"noDerivativesTrust200902" 
| "pre5378Trust200902" 


FS 12, 
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attribute ipr { text }?, 
attribute iprExtract { xsd:IDREF }?, 


[ a:defaultValue = "IETF" ] 
attribute submissionType { 
"IETF" | "IAB" | "IRTF" | "independent" 


}?, 
attribute docName { text }?, 


[ a:defaultValue = "en" ] attribute xml:lang { text }?, 
[ a:defaultValue = "false" ] 

attribute sortRefs { "true" | "false" }?, 

[ a:defaultValue = "true" ] 

attribute symRefs { "true" | "false" }?, 

[ a:defaultValue = "true" ] 

attribute tocInclude { "true" | "false" }?, 

[ a:defaultValue = "3" ] attribute tocDepth { text }?, 
attribute prepTime { text }?, 

[ a:defaultValue = "true" ] 

attribute indexInclude { "true" | "false" }?, 


attribute version { text }?, 


2016 


[ a:defaultValue = "Common,Latin" ] attribute scripts { text 


attribute expiresDate { text }?, 
link*, 

front, 

middle, 

back? 


Informational [Page 


128] 


RFC 7991 


The "xml2rfc" Version 3 Vocabulary 


+ link = 
+ element link ( 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute href { text }, 
+ attribute rel { text }? 
EN } 
front = 
element front { 
- title, author+, date, area*, 
- note* 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 
+ title, 
+ seriesInfo*, 
+ author+, 
+ date?, 
+ area*, 
+ workgroup*, 
+ keyword*, 
+ abstract?, 
+ note*, 
+ boilerplate? 
} 
title = 
element title { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute abbrev { text }?, 
+ attribute ascii { text }?, 
text 
} 
author = 
element author { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute initials { text }?, 
+ attribute asciilnitials { text }?, 
attribute surname { text }?, 
+ attribute asciiSurname { text }?, 
attribute fullname { text }?, 
attribute role { "editor" }?, 
+ attribute asciiFullname { text }?, 
organization?, 
address? 
} 
Hoffman Informational 
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++ 


ERRE EE AAA AAA AAA AA+ ++++++++ 


organization = 
element organization ( 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute abbrev { text }?, 
attribute ascii { text }?, 
text 
} 
address = 
element address { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
postal?, 
phone?, 
facsimile?, 
email?, 
uri? 
} 
postal = 
element postal { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
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((city | code | country | region | street)* | postalLine+) 


} 
street = 
element street { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
} 
city = 
element city { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
} 
region = 
element region { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
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code = 
element code { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 

} 


country = 
element country { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 

} 


postalLine = 
element postalLine { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 

} 


phone = 
element phone { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 

} 


facsimile = 
element facsimile { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 

} 


email = 
element email { 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute ascii { text }?, 
text 
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+ uri = 
+ element uri ( 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 
text 

} 
- address = element address { postal?, phone?, facsimile?, email?, 
- uri? } 
- postal = element postal { street+, (city | region | code | 
- country)* } 
- street = element street { text } 


- city = element city { text } 
- region = element region { text } 
- code = element code { text } 
—- country = element country { text } 
- phone = element phone { text } 
- facsimile = element facsimile { text } 
- email = element email { text } 
- uri = element uri { text } 
date = 
element date { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute day { text }?, 
attribute month { text }?, 
attribute year { text }?, 
empty 
} 
area = element area { text } 
workgroup = element workgroup { text } 
keyword = element keyword { text } 


- abstract = element abstract { t+ } 
area = 
element area { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 
} 
workgroup = 


element workgroup { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
text 


tet ttttrtrt+te st 
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+ keyword = 


+ element keyword { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ text 
+ } 
+ abstract = 
+ element abstract { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute anchor { xsd:ID }?, 
+ attribute pn { text }?, 
+ (dl | ol | t | ul)+ 
F } 

note = 

element note { 

= attribute title { text }, 
= t+ 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute title { text }?, 
+ attribute pn { text }?, 
+ [ a:defaultValue = "false" ] 
+ attribute removelInRFC { "true" | "false" }?, 
+ name?, 
+ (dal | ol | t | ul)+ 
+ } 
+ boilerplate = 
+ element boilerplate { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ section+ 
+ } 
+ middle = 
+ element middle { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ section+ 
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- middle = element middle { section+ ) 


section = 
element section ( 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 


attribute anchor { xsd:ID }?, 
7 attribute title { text }, 
attribute pn { text }?, 
attribute title { text }?, 
[ a:defaultValue = "true" ] 
attribute numbered { "true" | "false" }?, 
[ a:defaultValue = "default" ] 
attribute toc { "include" | "exclude" | "default" }?, 
(t | figure | texttable | iref)*, 
[ a:defaultValue = "false" ] 
attribute removeIlnRFC { "true" | "false" }?, 
name?, 
(artwork 
| aside 
| blockquote 
| dl 
| figure 
| 
| 
| 
| 


iref 

ol 
sourcecode 
t 

table 
texttable 
ul)*, 
section* 


HER +++++++++++ 
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element name ( 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute slugifiedName { text }?, 
(text | cref | eref | relref | tt | xref)* 


+++++++ 


— 


element t { 
attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
+ attribute pn { text }?, 
attribute hangText { text }?, 
[ a:defaultValue = "false" ] 
attribute keepWithNext { "false" | "true" }?, 
[ a:defaultValue = "false" ] 
attribute keepWithPrevious { "false" | "true" }?, 
(text 
\list 
figure 
xref 
bcp14 
cref 
em 
eref 
iref 


| 
| 
| 
| 
| 
= | cref 
| 
| 
| 
| 
| 
| 


+ 


\list 
relref 
spanx 
vspace) * 
strong 
sub 

sup 

tt 
vspace 
xref) * 


+ 


} 
aside = 

element aside { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 
(artwork | dl | figure | iref | Mist | ol | t | table | ul)* 


t+tetttttreeeeteetest 
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+ element blockquote { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute anchor { xsd:ID }?, 
+ attribute pn { text }?, 
+ attribute cite { text }?, 
+ attribute quotedFrom { text }?, 
+ ((artwork | dl | figure | ol | sourcecode | t | ul)+ 
+ | (text 
+ bcp14 
+ | cref 
+ | em 
+ | eref 
+ | iref 
+ relref 
+ strong 
+ | sub 
+ | sup 
+ DEE 
+ | xref) +) 
} 
\list = 
element list { 
7 attribute style { text }?, 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ [ a:defaultValue = "empty" ] attribute style { text }?, 
attribute hangIndent { text }?, 
attribute counter { text }?, 
+ attribute pn { text }?, 
t+ 
} 
aa o 
+ element ol { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute anchor { xsd:ID }?, 
+ [ a:defaultValue = "1" ] attribute type { text }?, 
+ [ a:defaultValue = "1" ] attribute start { text }?, 
+ attribute group { text }?, 
+ [ a:defaultValue = "normal" ] 
+ attribute spacing { "normal" | "compact" }?, 
+ attribute pn { text }?, 
+ li+ 
T } 
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element ul { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 


[ a:defaultValue = "normal" ] 

attribute spacing { "normal" | "compact" }?, 
([ a:defaultValue = "false" ] 

attribute empty { "false" | "true" }, 
attribute pn { text }?)?, 

1i+ 


} 
li = 
element li { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 


| (text 
| bep14 
cref 
E 
| eref 
| iref 
| relref 
| strong 
| sub 
sup 
| tt 
| xref)+) 
} 
dl = 
element dl { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 


a 


[ a:defaultValue = "normal" ] 
attribute spacing { "normal" | "compact" }?, 
[ a:defaultValue = "true" ] 
attribute hanging { "false" | "true" }?, 
attribute pn { text }?, 
(dt, dd)+ 
} 
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((artwork | dl | figure | ol | sourcecode | t | ul)+ 
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Q 
ct 
ll 


element dt { 


(text 
| bep14 
| cref 
em 
| eref 
| iref 
| relref 
| strong 
| sub 
| sup 
tt 
| xref)* 
} 
dd = 
element dd { 


| (text 
bcp14 
cref 
em 
eref 
iref 
relref 
strong 
sub 
sup 

tt 
xref) +) 


tet teettttrte terete eee e ee eee teteteegegegetgttttte es 
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attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 

((artwork | dl | figure | ol | sourcecode | t | ul)+ 
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xref = 
element xref { 


+ attribute xml:base 
+ attribute xml:lang { text }?, 


attribute target 


= [ a:defaultValue = "false" ] attribute pageno { "true" 
- "false" }?, 
+ [ a:defaultValue = "false" ] 
+ attribute pageno { "true" | "false" }?, 
[ a:defaultValue = "default" ] 
= attribute format { "counter" | "title" | "none" | "default" 
+ attribute format { "default" | "title" | "counter" | "none" 
+ }?, 
+ attribute derivedContent { text }?, 
+ text 
T } 
+ relref = 
+ element relref { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute target { xsd:IDREF }, 
+ [ a:defaultValue = "of" ] 
sl attribute displayFormat { "of" | "comma" | "parens" | "bare" 
}?, 
+ attribute section { text }, 
+ attribute relative { text }?, 
+ attribute derivedLink { text }?, 
text 
} 
eref = 
element eref { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute target { text }, 
text 
} 
iref = 
element iref { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute item { text }, 
[ a:defaultValue = "" ] attribute subitem { text }?, 
[ a:defaultValue = "false" ] 
attribute primary { "true" | "false" )?, 
+ attribute pn { text }?, 
empty 
} 
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{ text }?, 


xSd:IDREF }, 
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cref = 


element cref { 

attribute xml:base 
attribute xml:lang 
attribute anchor { 
attribute source { 
text 

[ a:defaultValue = "true" ] 
attribute display { "true" 
(text | em | eref | relref 


{ text }?, 
{ text }?, 
xsd:ID }?, 
text }?, 


} 


element tt { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text 
| bep14 
| cref 
| em 
| eref 
| iref 
relref 
strong 
| sub 
| sup 


} 


strong = 


element strong { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text 

| bep14 

| cref 
em 

| eref 

| iref 

| relref 

| sub 

| sup 
tt 

| xref) * 
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strong | sub | sup | tt | xref) * 
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sub = 


| 
| 
| 
| 
sup = 


a a 
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element em { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text 


bcp14 
cref 
eref 
iref 
relref 
strong 
sub 
sup 

tt 
xref) * 


element sub 
attribute 
attribute 
(text 


bcp14 
cref 
em 
eref 
iref 
relref 
strong 
EE 
xref)* 


element sup 
attribute 
attribute 
(text 


bcp14 
cref 
em 
eref 
iref 
relref 
strong 
EE 
xref)* 
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{ 
xml:base { text }?, 
xml:lang { text }?, 


{ 
xml:base { text }?, 
xml:lang { text }?, 
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spanx = 
element spanx { 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 
[ a:defaultValue = "preserve" ] 
attribute xml:space { "default" | "preserve" }?, 
[ a:defaultValue = "emph" ] attribute style { text }?, 
text 
} 
vspace = 
element vspace { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
[ a:defaultValue = "0" ] attribute blankLines { text }?, 
empty 
} 
figure = 
element figure { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
+ attribute pn { text }?, 
[ a:defaultValue = "" ] attribute title { text }?, 
[ a:defaultValue = "false" ] 
attribute suppress-title { "true" | "false" }?, 
attribute src { text }?, 
+ attribute originalSrc { text }?, 
[ a:defaultValue = "left" ] 
attribute align { "left" | "center" | "right" }?, 
[ a:defaultValue = "" ] attribute alt { text }?, 
[ a:defaultValue = "" ] attribute width { text }?, 
[ a:defaultValue = "" ] attribute height { text }?, 
+ name?, 
icets., 
preamble?, 
5 artwork, 
+ (artwork | sourcecode) +, 
postamble? 
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+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 


1 


ble 
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element table ( 
attribute 
attribute 
attribute 
attribute 
name?, 
iret*, 
thead?, 
tbody+, 
tfoot? 


} 


preamble = 
element preamble { (text | xref | eref iref cref | spanx)* } 
element preamble { 

attribute xml:base { text }?, 

attribute xml:lang { text }?, 

(text 


HERA +++++++ 
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bcp14 
cref 
em 
eref 
iref 
relref 
spanx 
strong 
sub 
sup 

EE 
xref)* 


xml:base { text }?, 
xml:lang { text }?, 
anchor { xsd:ID }?, 
pn { text }?, 
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artwork = 


element artwork ( 
[ a:defaultValue = "preserve" ] 
attribute xml:space { "default" | "preserve" }?, 


} 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
attribute pn { text }?, 

attribute xml:space { text }?, 


[ a:defaultValue = "" ] attribute name { text }?, 
[ a:defaultValue = "" ] attribute type { text }?, 
attribute sre { text }?, 

[ a:defaultValue = "left" ] 

attribute align { "left" | "center" | "right" )?, 
[ a:defaultValue = "" ] attribute alt { text }?, 

[ a:defaultValue = "" ] attribute width { text }?, 
[ a:defaultValue = "" ] attribute height { text }?, 
text* 

attribute originalSrc { text }?, 

(text* | svg) 


# https://www.rfc-editor.org/materials/format/SVG-1.2-RFC.rnc 
sourcecode = 
element sourcecode { 


} 


attribute xml:base { text }?, 

attribute xml:lang { text }?, 

attribute anchor { xsd:ID }?, 

attribute pn { text }?, 

[ a:defaultValue = "" ] attribute name { text }?, 
[ a:defaultValue = "" ] attribute type { text }?, 
attribute src { text }?, 

attribute originalSrc { text }?, 

text 


thead = 
element thead { 


} 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
EXF 


tbody = 
element tbody ( 


Hoffman 


attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
Ere 
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tfoot = 
element tfoot { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
Ek 
) 
tr = 
element tr { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
(td | th)+ 
} 
td = 
element td { 
attribute xml:base 
attribute xml:lang 
attribute anchor { 
[ a:defaultValue = 
[ a:defaultValue = 
[ a:defaultValue = 


| (text 
| bep14 
| br 
cref 
em 
| eref 
| iref 
| relref 
| strong 
| sub 
sup 
| tt 
| xref)*) 


+++t+t+++++++++++++t+t++t+t+t++t+t+t+t+t+t++t++t++tHtHH 
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{ text }?, 
{ text }?, 
xsd:ID }?, 


{ text }?, 
{ text }?, 
xsd:ID }?, 


{ text }?, 
{ text }?, 
xsd:ID }?, 


December 2016 


"0" ] attribute colspan { text }?, 
"0" ] attribute rowspan { text }?, 


"left" ] 


attribute align { "left" | "center" | "right" }?, 
((artwork | dl | figure | ol | sourcecode | t | ul)+ 
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element th { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
[ a:defaultValue = "0" ] attribute colspan { text }?, 
[ a:defaultValue = "0" ] attribute rowspan { text }?, 
[ a:defaultValue = "left" ] 
attribute align { "left" | "center" | "right" )?, 
((artwork | dl | figure | ol | sourcecode | t | ul)+ 
| (text 
| bep14 
| br 
| cref 
| em 
| eref 
iref 
| relref 
| strong 
| sub 
sup 


ttettttterererererertereee ete tetetest 


} 
postamble = 
element postamble { (text | xref | eref iref cref | spanx)* 
element postamble { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
(text | cref | eref | iref | spanx | xref)* 


++++ 
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texttable = 
element texttable { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute anchor { xsd:ID }?, 
[ a:defaultValue = "" ] attribute title { text }?, 
[ a:defaultValue = "false" ] 
attribute suppress-title { "true" | "false" }?, 
[ a:defaultValue = "center" ] 
attribute align { "left" | "center" | "right" )?, 
[ a:defaultValue = "full" ] 
attribute style { "all" | "none" | "headers" | "full" }?, 
+ name?, 
preamble?, 
ttcol+, 
ex, 
postamble? 
) 
ttcol = 
element ttcol ( 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 
attribute width { text }?, 
[ a:defaultValue = "left" ] 
attribute align { "left" | "center" | "right" +2, 
+ (cref | eref | iref | xref | text)* 
T } 
+G 
+ element c { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ (text | cref | eref | iref | spanx | xref)* 
+ } 
+ bcp1l4 = 
+ element bcp14 { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
text 
} 
- c = element c { (text | xref | eref iref | cref | spanx)* } 
- back = element back { references*, section* } 
+ br = 
+ element br { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ empty 
+ } 
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+ back = 
+ element back ( 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ displayreference*, 
+ references*, 
+ section* 
+ } 
+ displayreference = 
+ element displayreference { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
+ attribute target { xsd:IDREF }, 
+ attribute to { text } 
E } 
references = 
element references { 
= [ a:defaultValue = "References" ] attribute title { text }?, 
— reference+ 
+ attribute xml:base { text }?, 
+ attribute xml:lang ([ text }?, 
+ attribute pn { text }?, 
+ attribute anchor { xsd:ID }?, 
+ attribute title { text }?, 
+ name?, 
+ (reference | referencegroup) * 
} 
reference = 
element reference { 
+ attribute xml:base { text }?, 
+ attribute xml:lang { text }?, 
attribute anchor { xsd:ID }, 
attribute target { text }?, 
+ [ a:defaultValue = "true" ] 
+ attribute quoteTitle { "true" | "false" }?, 
front, 
-= seriesInfo*, 
= format*, 
= annotation* 
+ (annotation format refcontent seriesInfo)* 
+ } 
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ferencegroup = 

element referencegroup { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute anchor { xsd:ID }, 
reference+ 

} 

riesInfo = 

element seriesInfo { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute name { text }, 
attribute value { text }, 
attribute asciiName { text }?, 
attribute asciiValue { text }?, 
attribute status { text }?, 


[ a:defaultValue = "IETF" ] 
attribute stream { "IETF" | "TAB" "IRTE" 
empty 

} 

rmat = 


element format { 
attribute xml:base { text }?, 
attribute xml:lang { text }?, 
attribute target { text }?, 
attribute type { text }, 
attribute octets { text }?, 
empty 
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| "independent" }?, 
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annotation = 


} 


} 


tet ttetettrtrtrttrerererereretete tee test 
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element annotation { 
spanx)* } 
start 
element annotation { 


= rfc 


attribute xml:base 
attribute xml:lang 
(text 


bcp14 
cref 
em 
eref 
iref 
relref 
spanx 
strong 
sub 
sup 

tt 
xref) * 


refcontent = 
element refcontent { 


attribute xml:base 
attribute xml:lang 
(text | bcp14 | em 


start |= rfc 


(text xref 


{ text }?, 
{ text }?, 


{ text }?, 
{ text }?, 


| strong | sub | sup | tt)* 
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